md5 on the fly or md5 in deb, RIPEMD-160 vs MD5
On Sat, Dec 20, 1997 at 04:28:02PM +1100, Hamish Moffatt wrote:
>Well, calculation at install time doesn't prevent somebody
>modifying the .deb (which is easy), especially in the case
>of non-official sites. Does dpkg check the MD5sum with
>the one in the Packages file or in the archive itself?
>Even then you could still tamper with an archive
>and recalculate the MD5sum for the Packages
>file or whatever. The only way to be really sure is
>the .dsc file I guess, which is pgp-signed by the
>real author.
True. But there is still value in md5s other than for security
purposes as has been validated in the other thread, namely integrity
checking.
Are MD5s part of a package? Are they REALLY intrinsic to packages.
IMHO they are more part of the package management process rather than
the package binary itself, though it's certainly a blurred line.
The only advantage of calculating MD5s on the fly:
1)the burden would be removed from the package maintainer
2)better separation of packages from package management processes
3)smaller binary distributions ( almost pointless argument )
4)could be an option for the /etc/dpkg/dpkg.conf
Advantages of having MD5s in the packages themselves:
1)all the information is there and it simplifies the package manager (+)
2)reduced overhead for package overhead a lot (+)
After all is said and done I think I'd like to see the MD5s in the *.deb
as well. Not enough benefits from doing it otherwise. As far as dealing
with trojan packages goes, isn't there a list of all md5sums for all packages
that is PGP signed by an official member ????
If there is one, then that list should be updated every time new packages
are added to the distribution, and the signed list of MD5s on the *.deb
SHOULD be sufficient for security checking.
Maybe somebody should give RIPEMD-160 a thought as an addition/replacement
for MD5. Check out http://www.esat.kuleuven.ac.be/~bosselae/ripemd160.html
for some more info. I kind of like the RIPEMD idea, and looks like there is
already an optimized version. There is also SHA-1 which is 160bit.
Maybe we should use, all three, just two, on? I'd say just one but either way
might as well pick a decent one, like one of the 160big ones.
Radu
Reply to: