Re: [PATCH 2/2] push -s: skeleton

From: Jeff King <peff@peff.net>
Date: Sep 9, 2011, 15:34 UTC
Message-ID: <20110909153441.GB28480@sigill.intra.peff.net>
In-Reply-To: <7v7h5iwub9.fsf@alter.siamese.dyndns.org>

On Thu, Sep 08, 2011 at 03:19:54PM -0700, Junio C Hamano wrote:

Show 9 quoted lines

> Jeff King <peff@peff.net> writes:
> 
> > Yeah, it is a potential problem, but it just seems wrong to put too much
> > policy work onto the server.
> 
> My take on it is somewhat different. The only thing in the end result we
> want to see is that the pushed commits are annotated with GPG signatures
> in the notes tree, and there is no reason for us to cast in stone that
> there has to be any significance in the commit history of the notes tree.

Hmm. Is order really irrelevant? If you push a commit to master, moving it from X to Y, then push-rewind it back to X, then push a new commit Z, how do I cryptographically determine the correct final state of master?

I'll see two push-certs, one going X..Y and one X..Z. They'll have timestamps, which can be used for ordering. But what if the first and third actions above are done by different people. Now you're trusting that their clocks are synced to order them properly.

Note that simply keeping an unsigned but ordered notes history doesn't solve this problem, either; you'd probably want a parent pointer in your push cert saying "and this is the previous push cert I am based on".

And maybe this is a use case we don't care about. Maybe it's enough for the push-cert to say "at some point in time, I thought it was a good idea to push these commits into master; signed, me".

But I'm not really clear on exactly what the security goals are. The series you sent looks interesting, but I haven't seen the verification side of these signatures. What are they going to be used for? What guarantees are we attempting to provide? For that matter, what is our threat model? What are attackers capable of?

Show 7 quoted lines

> In a busy hosting site that has many branches being pushed simultaneously,
> it is entirely plausible that the server side may just want to store each
> received push certificate in a new flat file in a filesystem, and have
> asynchronous process sweep the new certificates to update the notes tree,
> possibly creating a single notes tree commit that records updates by
> multiple pushes, for performance purposes, in its implementation of
> record_signed_push() in receive-pack.

OK, I see. It is not "the server can do whatever it likes with the information" as much as "the server can do whatever it likes, but at the very least should eventually create a notes tree of a given form".

-Peff