On Aug 3, 2008, at 11:38 AM, michael@stroeder.com wrote:
Full_Name: Michael Ströder Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.163.112.78)
Source files downloadable fomr http://www.openldap.org should be digitally signed. It's common practice to use PGP (GnuPG) for that.
Saying this should be done solely because you claim it is "common practice" is lame. It would be better to state what attacks you worry about, and why you think providing digital signatures using a trustworthy signing key, and what requirements are for this trustworthy signing key.
But I note the practice is, itself, lame. Often there is no reason to trust the signing key other than where the link to the signing key was published. Often the signature itself is not widely published, or errors in providing it too far common to raise concerns in case the signature publication fails (by error or attack).
For instance, web_ldap says it provides a signature for a digital release, but clicking on the link provides a page which says "Not found". Maybe your releases have been hacked, but most likely its just publication issue. Most verifiers faced with such such a "Not found" message will just not perform the verification. Often they won't even bother to raise an issue to the publisher.
And if an attacker successfully takes over the main website, we have to realize that they can replace everything. Maybe they will replace whatever text we have about digital signatures with a statement that signatures are no longer provided, and then delete them. Or they may fake publication errors. They could even fake an email to the announcement list that signatures are temporarily not provided due to operational reasons, or announce a new signing key.
Fortunately, it is unlikely that such an attack would go unnoticed for long period of time. I would argue that if takeover was a major threat (which it might well be), that more time should be spent detecting a takeover (we have some in place).
I also find it interesting that you suggest signing tarballs and not announcement messages. I note that an attacker need not modify a tarball, or cause a new tarball to be distributed, to successfully mount an attack against the downloader. One could simply point "stable" to a known problematic release. As the signature for the problematic release would be valid, it doesn't help the downloader in detecting they got the wrong release. Of course, even if you sign release messages, the attacker can still replace the current messages with prior ones whose signatures would still be valid.
But, as I noted with hashes, the fact that release messages are widely published may make it more likely that such problems will be detected.
I note as well that properly deploying release signing requires more than script modification. For instance, one does need to consider that the host to sign the releases might itself been taken over and the implications of such a takeover. Also, in signing announcements, considerable testing would need to take place to ensure produced signatures were actually verifiable (lots of things muck with email in ways that invalid email signatures).
Anyways, for this to go anywhere, I think you or others advocating it need to more precisely state which attacks you concerned about, how you think digital signatures will help, and detail requirements on that signing (in particular, requirements on signing key so trust can be established and maintained).
I note that GNU PGP folks say that verification of a wide published message digest is sufficient to ensure the integrity of their releases.
Basically, PGP signing here offers little value as an attacker who has supplanted the other protections (namely widely distributed message digests) is in position to convince most every downloader than the current release is not signed, or was signed but that signature is not currently available, or was signed by some key other than that previously used by the distributor.
Note that these are human-factor attacks, not attacks based upon any weakness in the PGP signing standards or implementations.