| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
On Wednesday 24 March 2004 14:47, Jesse Nelson wrote: |
| 5 |
> |
| 6 |
> not bout stopping intrusion just that its a verry likely poisioning |
| 7 |
> scenario, and even if the signing key dies after 1 day.. if i got root |
| 8 |
> on the server i just update. besides now theres 1 days worth of sync's |
| 9 |
> out in the wild with compromised builds/pataches/binaries. |
| 10 |
|
| 11 |
What I want to say is that it is more likely that the compromised time |
| 12 |
will be longer anyway so the (on average) 1/2 day extra doesn't matter |
| 13 |
that much. |
| 14 |
|
| 15 |
> > There is no way to stop this before that person is identified in any |
| 16 |
> > case. After this person is identified his keys will be revoked and |
| 17 |
> > all the packages signed by him/her are invalid. They will need to be |
| 18 |
> > resigned by someone else to be valid again. |
| 19 |
> |
| 20 |
> you can stop this buy: |
| 21 |
> having multiple eyes have to see the changes b4 a commit to rysnc |
| 22 |
> servers, and it follows that you would then have multiple sigs for a |
| 23 |
> item (build/dist/patch) etc or multiple sigs on a sums file. |
| 24 |
|
| 25 |
It would only change the case so that 2 dev's private keys need to be |
| 26 |
compromised. It makes it more secure but not 100% secure. I think that |
| 27 |
100% secure is an illusion that we should not shoot for initially. |
| 28 |
Multiple signing while an improvement will increase security, but first |
| 29 |
get single signing in place and then do multiple signing. Single signing |
| 30 |
will be hard enough. |
| 31 |
|
| 32 |
> this could also go through a security review b4 goin out live. Instead |
| 33 |
> of say relying on ppl cross-checking. A defined security team could |
| 34 |
> have to sign b4 release, but i doubt eaither of these would go over |
| 35 |
> well with already overloaded devs. |
| 36 |
|
| 37 |
We don't have such a QA/security team and would need serious |
| 38 |
reorganization to implement such a system. This makes it practically |
| 39 |
impossible to implement within 6 months. |
| 40 |
|
| 41 |
> its a QA issue.. its really a process issue.. building QA/security |
| 42 |
> into the release cycle. |
| 43 |
|
| 44 |
Yes, it is. However with over 200 developers changing things overnight is |
| 45 |
like trying to change the direction of a mammuth oil tanker 90 degrees |
| 46 |
in 15 minutes. It is plain impossible. |
| 47 |
|
| 48 |
Paul |
| 49 |
|
| 50 |
ps. hint: things need to go by small nudges and lots of patience |
| 51 |
|
| 52 |
- -- |
| 53 |
Paul de Vrieze |
| 54 |
Gentoo Developer |
| 55 |
Mail: pauldv@g.o |
| 56 |
Homepage: http://www.devrieze.net |
| 57 |
-----BEGIN PGP SIGNATURE----- |
| 58 |
Version: GnuPG v1.2.4 (GNU/Linux) |
| 59 |
|
| 60 |
iD8DBQFAYZYKbKx5DBjWFdsRAvh4AJ4iLd2Dq1XVBmBontufwfGWRahf8wCfdKqj |
| 61 |
4Q0LtAnDGBxEeyja29vir4A= |
| 62 |
=pkvN |
| 63 |
-----END PGP SIGNATURE----- |
| 64 |
|
| 65 |
-- |
| 66 |
gentoo-dev@g.o mailing list |
Archives