In case you haven’t yet heard, the venerable ProFTPD code has been compromised, according to this posting:

On Sunday, the 28th of November 2010 around 20:00 UTC the main distribution server of the ProFTPD project was compromised. The attackers most likely used an unpatched security issue in the FTP daemon to gain access to the server and used their privileges to replace the source files for ProFTPD 1.3.3c with a version which contained a backdoor.

This isn’t the first time, and it won’t be the last time, unfortunately. Reading on in the report, I stumbled over a few lines which I’ve seen countless times:

The MD5 sums for the source tarballs are: 8571bd78874b557e98480ed48e2df1d2 proftpd-1.3.3c.tar.bz2 […]

I’m assuming you’ve seen that as well before. An MD5 sum is 128 bit MD5 hash taken from a file. On UNIX systems you’ll typically have an md5sum program to determine these:

    $ md5sum /etc/passwd
    4732518c5fe6dbeb8429cdda11d65c3d  /etc/passwd
    

These sums are typically put up on a Web site for you to verify against the downloaded file. So, if you do verify the sum, and I strongly doubt that most people would, you retrieve the file, calculate its MD5 sum and compare that sum to the number you found on the Web site. That is all very fine and dandy, if – and only if, you trust the Web site hasn’t been compromised together with the file you just downloaded. In addition to all of that, you have the PGP or GnuPG keys you can use to verify the download, but I doubt even more that people do this on a regular basis. (You know the deal: wget, tar xvzf; ./configure; make; no time for much verification there…) So the question I ask is: can I trust the MD5 sum I see on the Web site? If, and this is just an idea, I trust the signed DNS for the site, then surely I can trust an MD5 hash published via the DNS, can’t I? With DNSSEC getting here slowly but surely, we have a mechanism to distribute small blobs of data securely. So, why not distribute the MD5 hashes of files via the DNS? DNSSEC to be precise? I know, I know: you’ll all be saying: what??? Another bit of data in the DNS? What else should it carry? It contains CERTificates, SSH fingerprints, and what not, and now file MD5s? Sure, why not? And to add insult to injury, I’m going to suggest publishing those as a TXT resource record. Oh, no!, not another TXT format? Pourquoi pas? See RFC 1464 for some more neat ideas… :-)

    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1
    
    ;; ANSWER SECTION:
    proftpd-1.3.3c.tar.gz.example.net. 120 IN TXT "4f2c554d6273b8145095837913ba9e5d"
    

For the benefit of those of you who haven’t noticed, let me point out the two letters ad in the first line of the output above: Authenticated Data. This DNS server has confirmed that the TXT record has been authenticated by whoever manages the example.com zone. Now I don’t propose to construct the domain names like in the example above. Probably something along the lines of “remove all punctuation marks” in the package name, and tack on “.md5.example.net” to query the DNS for a TXT RR. Thoughts? So what, if the DNS server is on the same box? The important thing is that the DNSSEC signing keys aren’t on that box.