On Sat, Mar 26, 2011 at 10:12:10AM +0100, Andreas K. Huettel wrote: > 3) Rely on an existing key list somewhere distributed in portage; the list > file with the key id's (not the keys themselves) is signed with a master key. > Is a mediocre and potentially insecure workaround. > Pros: you can exactly decide what keys are used and trusted, without thinking > about GnuPG's inner workings. A user can edit his key and the key remains > trusted. > Cons: Mainly that the key id is a pretty short hash afaik.(Any > better-informed > people around?) 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. Security weakpoints: - 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? -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
pgpwQC5IuPHgi.pgp
Description: PGP signature
