> > 3) > 1. Generate said list L from the GPG fields in LDAP (w/ long-form keyids) > 2. Clear-sign L, produces L' > 3. Include L' in /metadata/ during rsync content build. > 3.1. Provide all L' files in a trusted Git repository for historical > reference. > 4. Tree-sign per GLEP58, such that signed list is included. > > Pros: > - L' is plaintext and works well w/ rsync deltas.
> Cons: Mainly that the key id is a pretty short hash afaik.(Any > better-informed > people around?) > - Introduces new weak point if attacker can compromise the automated > clear-signing service of #2. > > > 4) Rely on an existing list of keys somewhere distributed in portage and > > possibly somewhere else (keyservers); a key userid is signed with a master > > key. Work with GnuPG's well-tested and well-thought-out trust relationships. > > Back to start, time to re-read the entire thread... :) > What does this actually add over #3 in terms of security? I don't know. I am basically worried that we are using a well-tested cryptosystem in a hackish way and cannot fully estimate the consequences. (Which is why I hoped someone more knowledgable could comment. I may know approximately how to use gpg, and may have some basic knowledge of the maths behind it, but I have no clue of the data structures and software internals.) I'd say, here the burden of proof is on you. (i.e. that the signed list of long keyids is as secure as a list of signed keys) -- Andreas K. Huettel Gentoo Linux developer - kde, sci, arm, tex dilfri...@gentoo.org http://www.akhuettel.de/
signature.asc
Description: This is a digitally signed message part.
