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

[Patrick Lauer <patrick@gentoo.org>]

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

On Fri, 2006-05-19 at 10:46 +0100, Chris Bainbridge wrote:
> The only attack most people really care about is a compromised rsync
> server. There is no practical way to protect against the other attacks
> - and at the end of the day, if a developer gets compromised it
> doesn't matter whether it's a gpg key or ssh key, the effect is the
> same. 
The difference is how you handle any problems. You can't avoid it, but
you can reduce the impact.

> The discussion about which files to sign is pointless - the extra
> computational cost of signing all files in the tree is insignificant,
> and how are we supposed to know how future tools will handle things
> like the licenses? Just do it properly now and sign every file. 
In theory yes.
Practically you have to find a non-intrusive way so signatures are per
file.
There are potential problems with "special" files like package.mask that
will be modified often by different people ... signing that is a bit
silly

> We already trust the master cvs server admins (and they could just
> replace the whole tree anyway), so what benefit does a distributed
> signing system like gpg actually give to the developers or users? I
> can't see any that are worth the costs of key management (and there
> are costs, otherwise a system would've been put into place years
> ago). 
No central authority --> no single point of failure

Give me a central server and I will focus on hacking that ... hacking 50
developers is much harder ;-)

> So my simple proposal would be to use a single key, and a post-commit
> cvs hook to sign the whole tree. It takes me 1.5 seconds with gnupg to
> generate a signature covering the whole tree on my desktop here. I
> don't know how many commits per day there are (and maybe that would be
> reduced with an atomic commit system like svn), so I don't know if
> this is an acceptable cost. I think it probably is, but if not, then
> signing could be done per-directory. 
I don't see what that gains you ... what exactly does this signature
express?
and 1.5sec doesn't appear realistic to me, I'd expect it to take ~1
minute even on a fast system

> The benefits of this would be that changes are minimised - developers
> and users act the same, the impact on the tree is a 191 byte
> signature, and yet it will protect against the most likely and most
> practical form of attack. 
So ... DoS scenario
I just add one byte to the tree and the signature fails ... what then? 

> I was much more pro-distributed trust system in 2003 (or whenever this
> was last discussed), but I think the right solution now is the
> practical, easy to implement one.
I think I'd prefer a hybrid.

One possibillity would be:
- every dev signs as it is done now
- post commit an automated signature from a master key is added

so the normal user can check the master signature, and the paranoid
people can use the per-dev keys.

Where I fully agree is "practical" and "low impact" - it should be easy
to use so that everyone can use it without lots of configuring. This of
course limits the complexity that we can allow.


wkr,
 Patrick
-- 
Stand still, and let the rest of the universe move

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]