Re: [gentoo-dev] Re: rejecting unsigned commits

[Robin H. Johnson]

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     : robbat2@g.o
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85