On Thu, 18 May 2006 23:45:17 +0200 Patrick Lauer <[EMAIL PROTECTED]> wrote:
> Note: a possible defense against rogue devs would be multi-signing, I don't think it's worth trying to defend against rogue devs. We have to have some level of trust amongst devs; anyone abusing that trust will be ejected sooner or later and any breakage will be fixed. On key management - I wouldn't get too excited about gold standard key management. Using the "web of trust" seems good enough to me. The default chain depth of 5 seems enough to reach around the globe. Publish the top-level public key(s) and fingerprint(s) on the web server, have the secret keys held by infra, revocation certificates by infra and council. Anyone not wishing to trust the web server can locate a nearby dev whose identity they can trust with a chain back to the top and obtain the public key from that dev. Perhaps we could take a more proactive approach to getting devs keys onto the chain. I wanted to mention the currently un-signed portions of the tree. I'm sure we've discussed this before although I couldn't find it. Unsigned bits of the rsync tree are: eclass licenses metadata profiles header.txt scripts skel.* obviously header.txt and skel.* aren't important. scripts isn't too important either, although a manifest-style file in there wouldn't be difficult. licenses and metadata don't have any security impact so there's little point there, also. do profiles present a security risk? Perhaps by masking/unmasking fixed/vulnerable versions of packages. Here, a Manifest in each directory seems most sensible (it might be useful to move the global data around a bit; fex move *desc into the desc subdirectory). eclass - not so easy. A per-eclass detached signature would clutter the directoryup too much, doubling the file count. A single Manifest for the whole directory could be awkward if enough eclass editing goes on simultaneously, but it might be workable. I think that's where the last discussion ended up - a single manifest for the whole eclass directory. If GLEP33 ever gets implemented, this issue is obvious as each subdirectory would have its own manifest. Obviously the best way to add this sort of thing is to add support to repoman, which has been mentioned before for profiles at least, for QA. -- Kevin F. Quinn
signature.asc
Description: PGP signature
