| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
On Thursday 25 March 2004 10:39, Jesse Nelson wrote: |
| 5 |
> > |
| 6 |
> > These are the two situations that worry _me_ the most: |
| 7 |
> > |
| 8 |
> > 1. A package source code is compromised at the main distribution |
| 9 |
> > site (or one of it's mirrors). |
| 10 |
> > |
| 11 |
> > This has happened in the past and if I remember correctly, |
| 12 |
> > Gentoo linux was able to discover at least one such trojan. |
| 13 |
> > The source code had been tampered with, but fortunately, the |
| 14 |
> > ebuild digest of that package was able to notice that. This |
| 15 |
> > was pure luck, since if the ebuild developer had made his |
| 16 |
> > digest _after_ the source code had been compromised, we'd all |
| 17 |
> > be running trojans today (well, maybe). |
| 18 |
> > |
| 19 |
> > Having the ebuild developer _sign_ the digest wouldn't help |
| 20 |
> > at all. If the original author of the source code had a source |
| 21 |
> > code signature, then if gentoo had a mechanism to verify that, |
| 22 |
> > then it would have helped. |
| 23 |
> |
| 24 |
> Code review is only way to stop this most of the time. The other side |
| 25 |
> of it is that many projects provide gpg sigs of the source. one could |
| 26 |
> incorporate that as well into the distribution. Which would catch and |
| 27 |
> post signing mods. Again not gonna detect anything thats gotten in |
| 28 |
> there during that projects dev cycle. |
| 29 |
|
| 30 |
Dev's are expected to go through reasonable efforts to ensure that the |
| 31 |
source files they get are correct. We cannot aim however to protect |
| 32 |
against trojaned source files that seem to be valid at the moment they |
| 33 |
are downloaded by the gentoo developer. After that we can trust the |
| 34 |
gentoo digests, further checking the original source signature is not |
| 35 |
needed. |
| 36 |
|
| 37 |
> Aside from every piece of code going through review i think you gotta |
| 38 |
> just accept this risk and make a system that can easly invalidate any |
| 39 |
> package that may be discovered after the fact, and incorporates the |
| 40 |
> security thats provided by the author (usually a gpg sig). |
| 41 |
|
| 42 |
This is indeed what needs to be done. |
| 43 |
|
| 44 |
> > 2. An gentoo rsync mirror is compromised. |
| 45 |
> > |
| 46 |
> > There are loads of mirrors, and no way to know how secure each |
| 47 |
> > of them are. A compromised mirror may cause a lot of damage. |
| 48 |
> > If all ebuilds were signed, then such a security breach |
| 49 |
> > wouldn't be much of a threat. |
| 50 |
> |
| 51 |
> yup esp with 1+N sigs etc. (/me beats dead horse) |
| 52 |
|
| 53 |
This case we are trying to combat especially. N > 1 sigs is problematic |
| 54 |
though. Please do not consider it for ebuild signatures at this point. |
| 55 |
The problems are organizational and would require many changes to |
| 56 |
manifests and/or ebuilds to allow incremental signing. |
| 57 |
|
| 58 |
Paul |
| 59 |
|
| 60 |
- -- |
| 61 |
Paul de Vrieze |
| 62 |
Gentoo Developer |
| 63 |
Mail: pauldv@g.o |
| 64 |
Homepage: http://www.devrieze.net |
| 65 |
-----BEGIN PGP SIGNATURE----- |
| 66 |
Version: GnuPG v1.2.4 (GNU/Linux) |
| 67 |
|
| 68 |
iD8DBQFAYq20bKx5DBjWFdsRAn9PAKDSL3OQ2g3fNHhHSJc3ECSVnfOZ6QCghNpt |
| 69 |
HI3wAxVntLNmrL/G46U+m18= |
| 70 |
=/YWS |
| 71 |
-----END PGP SIGNATURE----- |
| 72 |
|
| 73 |
-- |
| 74 |
gentoo-dev@g.o mailing list |
Archives