I don't know if this is helpful, but this is how I think package
signing and verification should work:
1) When a package is built using dpkg-buildpackage, a certificate is
generated and PGP signed (our changes file does this - Klee is
working on more detailed certificates too). What the certificate
proves is that the package was compiled by somebody who has the
private key and knows the passphrase. The person that did this
should know where all the source came from and be reasonably
sure that his system wasn't compromised.
2) When a package is injected into a server (this goes for any server,
including mirror sites and alternate distributions, not just master),
the server which accepts the package should make sure the package
comes from a source where it is possible to verify the identity of
the person who built it. We are currently doing this.
As long as we do these 2 things properly, we don't have too much to
worry about. If we fail to do this at some point in the chain, we
lose accountability/protection for the people and machines involved.
For the automated compiling systems, I think the obvious solution is to
just create PGP keys for the systems doing the compiling, and add them
to the maintainer keyring so that master will accept their uploads.
The automated compiling systems would log everything they accept as
input to a public mailing list. This way, if one of the compiling
systems is compromised -- and a trojan horse somehow gets added to a
package, we would have enough data to figure out what point in the
chain this occurred. Then it would just be a matter of doing some
detective work to try to ferret out the wily hacker/cracker.
Cheers,
- Jim
Attachment:
pgplcW_lMZl1z.pgp
Description: PGP signature