| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
On Thursday 25 March 2004 01:03, Chris Bainbridge wrote: |
| 5 |
> You know that keys are good because the associated KeyID is in the |
| 6 |
> ACL. The ID can't get in the ACL unless enough people, who are already |
| 7 |
> in the ACL, sign the new manifest. If someone revokes their key, then |
| 8 |
> the minimum number of developers have to sign the new manifest with |
| 9 |
> the new ACL included. |
| 10 |
|
| 11 |
I have a number of questions: |
| 12 |
- - How do you know that I didn't just create a new ACL file (maybe for a |
| 13 |
new package) and signed it myself, and used it to give myself access to |
| 14 |
this package and add malicious code. |
| 15 |
|
| 16 |
- - How do you propose all those ACL's get created. Especially as we don't |
| 17 |
want to limit who may commit where. In some cases it is actually |
| 18 |
essential that certain parties (managers) perform fast commits on a |
| 19 |
package they are not normally involved with. |
| 20 |
|
| 21 |
> This system does not introduce a huge amount of work for a developer. |
| 22 |
> Revocations - just check that the ACL has the keyId removed, sign the |
| 23 |
> new manifest, and checkin the signature. Updated ebuild - sign the |
| 24 |
> manifest, checkin the signature. Updated important package requiring |
| 25 |
> minimum number of developers to sign a release - sign manifest, |
| 26 |
> checkin signature, send email to other developers requesting they |
| 27 |
> check release and do the same. |
| 28 |
|
| 29 |
The current IMPLEMENTED system is even less work for developers. An |
| 30 |
update just requires signing the manifest. This is done automatically by |
| 31 |
repoman so it just means one needs to enter his passphrase (or use |
| 32 |
gpg-agent) |
| 33 |
|
| 34 |
> In this mechanism it is not necessary to sign each others keys, or |
| 35 |
> have a master key. Each developer is responsible for their own key. |
| 36 |
> OpenPGP keyservers only store the public keys. Without a developers |
| 37 |
> private key it would be impossible to generate a valid signature. Even |
| 38 |
> if the keyserver is hacked, and a rogue public key inserted, the key |
| 39 |
> will not match the KeyID in the ACL (the GPG keyid is a hash of the |
| 40 |
> public key). It is not even necessary to implement key distribution - |
| 41 |
> given a signature or keyId gpg can automatically fetch a public key |
| 42 |
> from the openpgp keyserver network and verify that it is the correct |
| 43 |
> one. The only attack that would work is to compromise enough gentoo |
| 44 |
> developers private keys so as to be able to generate the minimum |
| 45 |
> number of signatures for a package. |
| 46 |
|
| 47 |
This approach still relies on minimum signatures being bigger than 1. |
| 48 |
While that would work for ACL's this will currently not work for |
| 49 |
manifests. It would put alternative architectures to a grinding halt and |
| 50 |
seriously limit the possibilities of the x86 development. |
| 51 |
|
| 52 |
Paul |
| 53 |
|
| 54 |
ps. Based on one public key on a single trusted source (A CD), how do you |
| 55 |
ensure that the whole tree is uncompromised. |
| 56 |
|
| 57 |
pps. How do you ensure that at a compromise of a key / or a rogue |
| 58 |
developer this key is invalidated even when revocation is not possible |
| 59 |
(like with a rogue developer) |
| 60 |
|
| 61 |
- -- |
| 62 |
Paul de Vrieze |
| 63 |
Gentoo Developer |
| 64 |
Mail: pauldv@g.o |
| 65 |
Homepage: http://www.devrieze.net |
| 66 |
-----BEGIN PGP SIGNATURE----- |
| 67 |
Version: GnuPG v1.2.4 (GNU/Linux) |
| 68 |
|
| 69 |
iD8DBQFAYqjKbKx5DBjWFdsRAkyBAJ9sQs7Gb0uDshp4j1QZWp98dg0OugCgp2mo |
| 70 |
UO6rR6hFCVwJYJFvlMN+PiM= |
| 71 |
=bRq2 |
| 72 |
-----END PGP SIGNATURE----- |
| 73 |
|
| 74 |
-- |
| 75 |
gentoo-dev@g.o mailing list |
Archives