Re: [PATCH 16/18] receive-pack: GPG-validate push certificates

From: David Turner <dturner@twopensource.com>
Date: Aug 20, 2014, 17:56 UTC
Message-ID: <1408557408.1282.5.camel@leckie>
In-Reply-To: <CAPc5daXLBQdjPaWNxmwZqStiWu8qHRfDG6=JS=bhbzA+c5Ww5g@mail.gmail.com>

On Wed, 2014-08-20 at 10:29 -0700, Junio C Hamano wrote:

Show 16 quoted lines

> On Wed, Aug 20, 2014 at 9:56 AM, David Turner <dturner@twopensource.com> wrote:
> > On Tue, 2014-08-19 at 15:06 -0700, Junio C Hamano wrote:
> >> Reusing the GPG signature check helpers we already have, verify
> >> the signature in receive-pack and give the results to the hooks
> >> via GIT_PUSH_CERT_{SIGNER,KEY,STATUS} environment variables.
> >>
> >> Policy decisions, such as accepting or rejecting a good signature by
> >> a key that is not fully trusted, is left to the hook and kept
> >> outside of the core.
> >
> > If I understand correctly, the hook does not have enough information to
> > make this decision, because it is missing the date from the signature.
> 
> The full certificate is available to the hook so anything we can do the hook
> has enough information to do ;-)  But of course we should try to make it
> easier for the hook to validate the request.

Excellent, then motivated hooks can do the right thing.

> > This might allow an old signed push to be replayed, moving the head of a
> > branch to an older state (say, one lacking the latest security updates).
> 
> ... with old-sha1 recorded in the certificate?

That does prevent most replays, but it does not prevent resurrection of a deleted branch by a replay of its initial creation (nor an undo of a force-push to rollback). So I think we still need timestamps, but parsing them out of the cert is not terrible.