If you ignore the clock skew between the pusher and the receiver, then
you are correct,
but otherwise not quite. Also by specifying that as <nonce>, not
<server-timestamp>,
the receiving end has a choice in how to generate and use the nonce
value. The only
requirement on the protocol is that the pusher must parrot it literally.
On Thu, Aug 21, 2014 at 4:59 PM, David Turner <dtur...@twopensource.com> wrote:
> On Wed, 2014-08-20 at 12:38 -0700, Junio C Hamano wrote:
>> David Turner <dtur...@twopensource.com> writes:
>>
>> > On Wed, 2014-08-20 at 10:29 -0700, Junio C Hamano wrote:
>> >> On Wed, Aug 20, 2014 at 9:56 AM, David Turner <dtur...@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.
>>
>> As I aleady mentioned elsewhere, a more problematic thing about the
>> push certificate as presented in 15/18 is that it does not say
>> anything about where the push is going. If you can capture a trial
>> push to some random test repository I do with my signed push
>> certificate, you could replay it to my public repository hosted at
>> a more official site (say, k.org in the far distant future where it
>> does not rely on ssh authentication to protect their services but
>> uses the GPG signature on the push certificate to make sure it is I
>> who is pushing).
>>
>> We can add a new "pushed-to <repository URL>" header line to the
>> certificate, next to "pushed-by <ident> <time>", and have the
>> receiving end verify that it matches to prevent such a replay. I
>> wonder if we can further extend it to avoid replays to the same
>> repository.
>
> I think but am not certain that pushed-to <repository URL>, along with
> the pushed-by <ident> <time> means that the nonce is not needed. The
> nonce might make replays harder, but pushed-to/pushed-by makes replays
> useless since the receiving server can determine that the user intended
> to take this action at this time on this server.
>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
