git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Junio C Hamano <gitster@pobox.com>
Date
Jan 14, 2015, 18:08 UTC
Message-ID
<xmqqr3ux9qwr.fsf@gitster.dls.corp.google.com>
In-Reply-To
<CAGZ79kad=c1wXW163doxWBRdSvQ7Y9EkkD+ZXtOfawjtxEyeQw@mail.gmail.com>
Stefan Beller <sbeller@google.com> writes:
Show 26 quoted lines
> On Mon, Jan 12, 2015 at 11:07 AM, Junio C Hamano <gitster@pobox.com> 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.

Previous: Stefan Beller
Message 11 of 11 in “receive-pack.c: only accept push-cert if push_cert_nonce was advertised”
  1. receive-pack.c: only accept push-cert if push_cert_nonce was advertisedStefan Beller, Jan 9, 2015
  2. Junio C HamanoJan 9, 2015
  3. Junio C HamanoJan 9, 2015
  4. Stefan BellerJan 9, 2015
  5. Junio C HamanoJan 9, 2015
  6. receive-pack.c: don't miss exporting unsolicited push certificatesStefan Beller, Jan 10, 2015
  7. Junio C HamanoJan 10, 2015
  8. Stefan BellerJan 10, 2015
  9. Junio C HamanoJan 12, 2015
  10. Stefan BellerJan 14, 2015
  11. Junio C HamanoJan 14, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.