One issue I've wanted to see addressed, but haven't, is why Debian packages aren't signed. It's the largest single weakness, and my one real complaint, against the whole Debian package system.
From the article, Jason Gunthorpe writes:
Red Hat has a single (hopefully) well-secured signing key that can only be used for packages that they produce in house. This is feasible 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 infeasible to sign every official package 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 maintainer's personal key for signatures. This brings up the really interesting question of 'who should sign a package'. With some 500 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, he can check the signature, but he also has 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.
The scheme I'd favor would be for a single-key signature for a full, stable release, and for the package-maintainer signature for development releases and individual packages. Yes, there are a lot of keys to track, but the number is finite, and a list of valid keys and/or a package/key crosswalk would be incorporated, or so it seems. The packaging system would then verify the signature, check that the proper signature was used, and report to the user any discrepencies. What weaknesses are there with this system?
There is obviously a problem with keeping the key list and crosswalk list current, and the list itself must be kept secure or otherwise validated.
For more information, see the Debian Weekly News article on the topic, and this list archive article (which has a good salesman joke to boot).
Karsten M. Self
SCO -- backgrounder on Caldera/SCO vs IBM
Support the EFF!!
There is no K5 cabal.