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? -- 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