1 |
On Thu, 2004-03-25 at 02:45, Robin H. Johnson wrote: |
2 |
> OK, after reading this entire thread, I've been thinking about a usable |
3 |
> implementation from both the administrative and developer perspective. |
4 |
> One of the most important things to remember in designing this, is that while |
5 |
> you can prevent damage from most individual attacks, no system in existence can |
6 |
> withstand a multi-faceted all-out assault. |
7 |
> |
8 |
> Goals: |
9 |
> ------ |
10 |
> - protect against compromised developer box / rogue developer |
11 |
> - protect against compromised rsync server |
12 |
|
13 |
Exactly how secure are we aiming at? The schemes presented here does |
14 |
nothing to secure gentoo boxes from malicious source code. |
15 |
|
16 |
If a patch is signed, with a good signature, does that mean that the |
17 |
signers has audited the patch for security holes? |
18 |
|
19 |
What is to say that the source compiled with an ebuild is not |
20 |
compromised? |
21 |
|
22 |
Of course we should do our part to make a secure transaction of source, |
23 |
but the costs has to be weighted to the gains. Any security scheme must |
24 |
be virtually transparent to the developers or it is not worth it, until |
25 |
we can secure the actual code. |
26 |
|
27 |
-John |