Re: [gentoo-dev] Signing everything, for fun and for profit

["Kevin F. Quinn" <kevquinn@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 2391 bytes --]

On Thu, 18 May 2006 23:45:17 +0200
Patrick Lauer <patrick@gentoo.org> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 191 bytes --]