On Tue, 9 May 2000, jeff covey wrote: > Jeff sent his reply to me only. Mine is not to wonder why; mine is > just to forward it to everyone else. :)
I think given what Jeff said I'd just like to mention basically the key point in the list thread I mentioned. RedHat has a single (hopefully) well secured signing key that can only be used for packages that they produce in house. This is feasable for them because their development is concentrated in one physical location, and they don't have the constantly changing archive like we do Debian has a similar key kept by the Security Team, but it is infeasable to sign every official pacakge that is created with this key, particularly since there are hundreds of new packages produced every single day. Though we have been talking about signing full releases with this key. So, in the Debian situation the next logical option is to use the maintainers personal key for signatures. This brings up the really interesting question of 'who should sign a package'. With some 500 keys signing keys the security of the whole scheme is in question. It is entirely possible to trojan an important package like libc using the most weakly secured key out of the 500. This same problem can be applied to upstream source packages too. If someone downloads a package they can check the signature, but they also have to *check the key*. The main point here is that just slapping a signature on packages does not necessarily make them as safe as the cryptosystem being used, or any safer than not having a signature. Jason
