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 ... > Cons: Mainly that the key id is a pretty short hash afaik.(Any > better-informed > people around?) You can use the long-format key IDs if you want. 0xB27B944E34884E85 is my long-form key.
> Am I missing something? In my tree-signing GLEPs, I explicitly pointed out that the developer signing of content only had real value for the developer->CVS part of the chain. Specifically, that while building the rsync tree for distribution, we can verify that the content we are preparing was indeed from a developer. Please re-read GLEP57. Everything in this thread been attempting to apply solutions to 'Process #1' (developer->infrastructure) to provide direct security for the end user after 'Process #2' (infrastructure->mirrors->users). What can we be certain of? 1. Developers should be signing manifests. 2. Infrastructure should be verifying those commits before pushing out to rsync. 3. Regardless of their choice of rsync or websync, users need to be able to verify that the tree that left Infrastructure was not modified in transit. RegI see so many bad ideas mentioned in this thread. The suggestions to keep a gpg-agent with a very long passphrase TTL just provides a massive new security hole: === Attacker breaks into developer's system, has access to SSH agent and GPG agent thanks to software like keychain, now can commit as that developer. === Is this the easiest attack? No, certainly not, looking at mirrors mirror, potentially a running deliberate selective malicious mirror would be much easier. -- 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
pgpDvfvXctmiO.pgp
Description: PGP signature
