| 1 |
On Thu, 18 May 2006 23:45:17 +0200 |
| 2 |
Patrick Lauer <patrick@g.o> wrote: |
| 3 |
|
| 4 |
> Note: a possible defense against rogue devs would be multi-signing, |
| 5 |
|
| 6 |
I don't think it's worth trying to defend against rogue devs. We have |
| 7 |
to have some level of trust amongst devs; anyone abusing that trust |
| 8 |
will be ejected sooner or later and any breakage will be fixed. |
| 9 |
|
| 10 |
|
| 11 |
On key management - I wouldn't get too excited about gold standard key |
| 12 |
management. Using the "web of trust" seems good enough to me. The |
| 13 |
default chain depth of 5 seems enough to reach around the globe. |
| 14 |
Publish the top-level public key(s) and fingerprint(s) on the web |
| 15 |
server, have the secret keys held by infra, revocation certificates by |
| 16 |
infra and council. Anyone not wishing to trust the web server can |
| 17 |
locate a nearby dev whose identity they can trust with a chain back |
| 18 |
to the top and obtain the public key from that dev. Perhaps we |
| 19 |
could take a more proactive approach to getting devs keys onto the |
| 20 |
chain. |
| 21 |
|
| 22 |
|
| 23 |
I wanted to mention the currently un-signed portions of the tree. |
| 24 |
I'm sure we've discussed this before although I couldn't find it. |
| 25 |
|
| 26 |
Unsigned bits of the rsync tree are: |
| 27 |
|
| 28 |
eclass |
| 29 |
licenses |
| 30 |
metadata |
| 31 |
profiles |
| 32 |
header.txt |
| 33 |
scripts |
| 34 |
skel.* |
| 35 |
|
| 36 |
obviously header.txt and skel.* aren't important. scripts isn't too |
| 37 |
important either, although a manifest-style file in there wouldn't be |
| 38 |
difficult. licenses and metadata don't have any security impact so |
| 39 |
there's little point there, also. |
| 40 |
|
| 41 |
do profiles present a security risk? Perhaps by masking/unmasking |
| 42 |
fixed/vulnerable versions of packages. Here, a Manifest in each |
| 43 |
directory seems most sensible (it might be useful to move the global |
| 44 |
data around a bit; fex move *desc into the desc subdirectory). |
| 45 |
|
| 46 |
eclass - not so easy. A per-eclass detached signature would clutter |
| 47 |
the directoryup too much, doubling the file count. A single Manifest |
| 48 |
for the whole directory could be awkward if enough eclass editing goes |
| 49 |
on simultaneously, but it might be workable. I think that's where the |
| 50 |
last discussion ended up - a single manifest for the whole eclass |
| 51 |
directory. If GLEP33 ever gets implemented, this issue is obvious as |
| 52 |
each subdirectory would have its own manifest. |
| 53 |
|
| 54 |
Obviously the best way to add this sort of thing is to add support to |
| 55 |
repoman, which has been mentioned before for profiles at least, for QA. |
| 56 |
|
| 57 |
-- |
| 58 |
Kevin F. Quinn |
Archives