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

Re: [PATCH] upload-pack: fix how ALLOW_ANY_SHA1 flag is disabled

From
Taylor Blau <me@ttaylorr.com>
Date
Oct 17, 2024, 15:23 UTC
Message-ID
<ZxEr4+sb4DfmtrKv@nand.local>
In-Reply-To
<20241017023735.GB1858436@coredump.intra.peff.net>
On Wed, Oct 16, 2024 at 10:37:35PM -0400, Jeff King wrote:
Show 20 quoted lines
> > I think it would probably make more sense to write this as:
> >
> >     data->allow_uor &= ~(ALLOW_ANY_SHA1 ^ (ALLOW_TIP_SHA1 | ALLOW_REACHABLE_SHA1));
>
> I think we have to treat them as a complete unit, as we don't know which
> bits were set by independent config lines and which were OR-ed in by
> ALLOW_ANY.
>
> So this case:
>
> > Stepping back a moment, I suppose this is handling the case where a user
> > writes:
> >
> >     [uploadpack]
> >         allowTipSHA1InWant = true
> >         allowReachableSHA1InWant = true
> >         allowAnySHA1InWant = false
> >
> > and is surprised when the final "uploadPack.allowAnySHA1InWant" unsets
> > the previous two options.
Yeah, I think that you and I are in agreement here.
Show 9 quoted lines
> is the one that Piotr is thinking about. But what about:
>
>   [uploadpack]
>   allowAnySHA1InWant = true
>   allowAnySHA1InWant = false
>
> Right now that pair is a noop, which is what I'd expect. But after the
> proposed patch, it quietly enables ALLOW_TIP_SHA1 and
> ALLOW_REACHABLE_SHA1.

That's an even clearer example of a new gotcha that would occur with this proposed patch, IMHO. I don't think in general that successive

    $ git config core.foo true
    $ git config core.foo false

should have any user-visible effect, as the latter should nullify the former.

> So I think the code has to stay the same, but we perhaps should document
> that "allow any" has the user-visible side effect of enabling/disabling
> the other two.

That would be a useful direction, I think. Double checking git-config(1), there is in deed no mention of allowAnySHA1InWant implying the other two options, which seems like a gap that would be good to address.

Piotr: what do you think?

Thanks, Taylor

Previous: Jeff KingNext: Piotr Szlazak
Message 4 of 14 in “upload-pack: fix how ALLOW_ANY_SHA1 flag is disabled”
  1. upload-pack: fix how ALLOW_ANY_SHA1 flag is disabledPiotr Szlazak via GitGitGadget, Oct 16, 2024
  2. Taylor BlauOct 16, 2024
  3. Jeff KingOct 17, 2024
  4. Taylor BlauOct 17, 2024
  5. Piotr SzlazakOct 17, 2024
  6. Taylor BlauOct 17, 2024
  7. Jeff KingOct 18, 2024
  8. Taylor BlauOct 18, 2024
  9. doc: document how uploadpack.allowAnySHA1InWant impact other allow optionsPiotr Szlazak via GitGitGadget, Oct 19, 2024
  10. Piotr SzlazakOct 19, 2024
  11. Piotr SzlazakOct 21, 2024
  12. Jeff KingOct 21, 2024
  13. Taylor BlauOct 21, 2024
  14. Taylor BlauOct 21, 2024

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.