Currently md5 is still used in a number of places in Debian. It's not used exclusively in them, but still software may fall back to md5, which must be avoided given that md5 is not the strongest hash nowadays, to put it mildly.
This page tries to list the places where we use md5 to protect the integrity of systems/packages/etc, and how and when we can move away from them.
[mjj29] Currently there are the following hashes to consider with their security statuses:
- md5 - should be treated as essentially completely broken and dropped yesterday
- sha1 - not actually broken yet as far as we know, but it will be the next to go and will be soon. Should be migrated away from at the earliest possible opportunity
- sha256 - on the 'still secure' list and likely to be for a reasonable length of time. Currently the best bet for use today
- sha3 - currently being developed via competition. This aims to solve some of the fundamental problems with the md5/sha1/sha256 family of hashes as well as all the actual breaks. Everyone should use this as soon as it's standardized.
Any changes made to switch from md5 should bear in mind that there will soon be another switch to sha3 and ensure that they are sufficiently agile to transition easily to other hash algorithms in the future.
apt/archive chain
- etch apt requires md5 in Release files.
- etch apt only verifies md5 in Release files.
- lenny apt does not require md5 in Release files
- lenny apt uses sha256 hashes in Release file (if available) - not sure about fallbacks
- neither etch nor lenny apt require md5 or sha1 in packages file
Stuff to do:
- non SHA256 hashes should be removed from Packages files right now (for lenny and later - so we don't break upgrades from sarge to etch)
- in post lenny release files we should remove non-sha256 hashes
- apt in lenny or later should be taught to never accept sha1 or md5 sums in release or package files (i.e. ignore md5/sha1, require sha256)
d-i/source chain
The etch dpkg source chain produces only md5 hashes in its .dsc and .changes files. Later versions include other hashes also:
- d-i should require sha256 in .dsc and .changes files for uploads targetting anything but etch (and its related repositories).
- for uploads to etch d-i would still accept .dsc and .changes files only listing md5 sums
- dpkg should probably be changed to only list sha256 (and drop sha1 and md5) from its files once d-i and the dpkg-source etc in stable accepts that.
other things
- debian-keyring and debian-archive-keyring have md5sums.txt (plus .asc) in their source file. debian-keyring uses it for verifying keyrings on rsync.
- what does debmirror use?
- what else is parsing packages files?
- and .dsc/.changes files
- dpkg (conffiles) - I thought this was only to detect if the admin modified the file, and if so maybe even a CRC32 would do. Assuming this is correct then we need not worry about md5 for this use case. And anyway, the nicer solution to this - if it was a problem - is to simply store the original file. Then we can do fancy things with 3way diff etc also. -- weasel
cdimages have MD5 and SHA1 only - is anything checking them in an automated way? If not we probably don't particularly care -- weasel.
jigdo uses md5 internally to track files, so debian-cd also depends on the md5 at build time. Could reasonably easily be moved over to other checksums, but will need people to work on updating the jigdo client too. -- SteveMcIntyre
- PAM (do we care?)