| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
On Wednesday 24 March 2004 15:16, Jesse Nelson wrote: |
| 5 |
> |
| 6 |
> um per package security with multiple sigs definatly prevents a |
| 7 |
> single dev or dev key from compromising integrity. Asuming that |
| 8 |
> ememger on sync or on build is forced to check for multiple sigs, and |
| 9 |
> then yell/scream if somthing only has one or none etc. Of course that |
| 10 |
> would have to be somthing settable in make.conf etc. This does not |
| 11 |
> however solve the event of a malicious comspiracy. |
| 12 |
|
| 13 |
I totally agree with you that multiple signatures are better. It is also |
| 14 |
however impossible to implement this within any realistic timeframe. I |
| 15 |
believe it is better to first use the allready existing single signing |
| 16 |
infrastructure and enhance it as time goes. |
| 17 |
|
| 18 |
> well part of gettin your dev key into the keyring in the firsplace |
| 19 |
> would require that you go through some sort of verification. this is |
| 20 |
> true weather or not your issuing certs or gpg keys, and the persons |
| 21 |
> pasphrase is what is verify weather or not he/she is who they say they |
| 22 |
> are, unless you propose sending biometric devices to every dev i don't |
| 23 |
> see how you can do this with any more confidence any other way. Debian |
| 24 |
> has a nice process for gpg key submittals: |
| 25 |
> http://www.debian.org/devel/join/nm-step2 |
| 26 |
|
| 27 |
It will be very hard to verify the names of all devs. It is also not |
| 28 |
needed. A dev is chosen because he/she shows qualities. This developer |
| 29 |
is identified based on his email address and/or IRC nick. It is quite |
| 30 |
hard to forge that you are this person if you are not actually him. It |
| 31 |
would require you to monitor multichannel communication on such a level |
| 32 |
that you would be equally capable in gentoo development. |
| 33 |
|
| 34 |
> well you can have a list of valid sigs for a particular package. |
| 35 |
> defining whose allowed to sign a that "package", but really your |
| 36 |
> asking for some ACL's here related to users and whatnot. which should |
| 37 |
> be enforced in your rcs not really by your signing system IMHO. |
| 38 |
|
| 39 |
We have just had the discussion for ACL's on CVS and decided not to do |
| 40 |
this. This means that package level access lists is also out of the |
| 41 |
question as it does the same. |
| 42 |
|
| 43 |
> actually p2p distribution in combination with multiple sigs lend to |
| 44 |
> each other quite well. Once a file or set of files is signed by 3 |
| 45 |
> parties @ those sigs are part of your installed gentoo keyring (and |
| 46 |
> verifiable outside that). you can have pretty high confidence that |
| 47 |
> what your pulling from joe users box is prsitine (pristine being what |
| 48 |
> the gentoo devs had released/signed etc). |
| 49 |
|
| 50 |
I don't see how using p2p instead of rsync for small files such as |
| 51 |
ebuilds makes any sense. Searching the file probably takes more time |
| 52 |
than just using rsync. Of course in p2p you need to have guarantees that |
| 53 |
what you receive is what you intended to receive, but what we need is |
| 54 |
different than p2p and a p2p architecture is not necessary suitable for |
| 55 |
us. |
| 56 |
|
| 57 |
Paul |
| 58 |
|
| 59 |
- -- |
| 60 |
Paul de Vrieze |
| 61 |
Gentoo Developer |
| 62 |
Mail: pauldv@g.o |
| 63 |
Homepage: http://www.devrieze.net |
| 64 |
-----BEGIN PGP SIGNATURE----- |
| 65 |
Version: GnuPG v1.2.4 (GNU/Linux) |
| 66 |
|
| 67 |
iD8DBQFAYaNGbKx5DBjWFdsRAj3sAKDIOM5QRJO8Yy0TLVVDEasYcc2lNQCdHIVk |
| 68 |
u9+mnkHhEbs6E+zDdrpFOxM= |
| 69 |
=xz9f |
| 70 |
-----END PGP SIGNATURE----- |
| 71 |
|
| 72 |
-- |
| 73 |
gentoo-dev@g.o mailing list |
Archives