Stefan Beller <sbeller@xxxxxxxxxx> writes: > On Mon, Jan 12, 2015 at 11:07 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >>> >>> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html