Re: [PATCH] receive-pack.c: don't miss exporting unsolicited push certificates

Stefan Beller [off-list ref] writes:

On Mon, Jan 12, 2015 at 11:07 AM, Junio C Hamano [off-list ref] wrote:

quoted

quoted

yes that's what I was trying to hint at. The hook would just see
it is unsolicited instead of not having the state available.

OK.  That makes sort of sense.  So if we:

 1) did not apply either patch (i.e. we accept unsolicited
    certificate, and the fact that we did not exchange "give me this
    nonce" "here is your nonce" is conveyed to the hooks by the lack
    of GIT_PUSH_CERT_NONCE environment and possible presense of
    unsolicited nonce in the GIT_PUSH_CERT blob); and then

 2) applied this patch first (i.e. we still allow unsolicited
    certificate, and the same fact is now conveyed to the hooks also
    by GIT_PUSH_CERT_NONCE_STATUS=UNSOLICITED if they sent a nonce,
    or GIT_PUSH_CERT_NONCE_STATUS=MISSING); and then finally

 3) applied the other patch to reject unsolicited certificate.

then we can stop at any of these three steps and the behaviour of
three resulting systems make sense and the pre-receive hook can
reject unsolicited certificates if it wants to, even at step #1.

I do not quite understand the intention of your mail. Are you saying I should
make a patch series to solve the problems as outlined above?

Not really.  All I was saying was that a hypothetical patch series
that progressed in the order above would "make sort-of sense".

I was hoping that readers would ask themselves this question: if we
know that our endgame will be #3, then does it still make much sense
to have the state that only patch #2 is applied?

I think #3 makes #2 unnecessary, as we always ask for nonce when
advertising push-cert capability in the released versions of Git, so
we might get an unsolicited push-cert (which #3 will reject), but we
will never see an unsolicited nonce in a push-cert, as long as we
told the pusher that it is OK to send a push-cert to us.