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

[Chris Bainbridge]

On 19/05/06, Patrick Lauer <patrick@g.o> wrote:
> On Fri, 2006-05-19 at 10:46 +0100, Chris Bainbridge wrote:
> > 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 ;-)

There are now several hundred gentoo developers. It is more likely
that one of them has a security lapse than cvs.gentoo.org.

> > 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

It is a single signature across the entire portage tree. It means that
after rsync emerge can check the signature against the retrieved tree
to validate the whole tree (or overlay).

Instead of guessing performance, test it. We can assume that disk
activity is negligible  - we have a dedicated server, and the portage
tree is ~115MB, so most of it will be cached in main memory. In
particular there is no disk seek latency. To simulate that we can
gather everything into a single file (which also has the side effect
of pulling into the cache) and then gpg sign that file:

find /usr/portage -path '/usr/portage/metadata' -prune -o -path
'/usr/portage/distfiles' -prune -o -path '/usr/portage/packages'
-prune -o -type f -exec cat {} > /tmp/blah \;
time gpg --detach-sign -a /tmp/blah

I get 1.5 seconds on a desktop and 6.5 seconds on a laptop.

> > 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?

Emerge informs the user that the rsync server has been corrupted and
terminates. How would this be any different with distributed file
signing? You have to rsync the entire tree, and then verify it - at
that point the tree is already corrupt. Ideally overlayfs (or just
plain old keeping a backup) could be used to restore the pre-sync
tree.

> > 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.

It could be done in stages. Start with the (easier) central key, then
later add distributed keys. I think a hybrid system would be the ideal
system, but realistically, bug #5902 has been around since March 2003
and no real progress has been made. The main sticking point seems to
be disagreements over key management and policies. I would hope that
most people could agree that a single key with a post-commit signing
is better than what we have now, and could be easily implemented,
whilst leaving open the option of a hybrid system implementation at a
later date.

-- 
gentoo-dev@g.o mailing list