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

Re: [PATCH 0/3] --end-of-options marker

From
Jeff King <peff@peff.net>
Date
Aug 6, 2019, 23:43 UTC
Message-ID
<20190806234319.GA19178@sigill.intra.peff.net>
In-Reply-To
<20190806225853.GH118825@genre.crustytoothpaste.net>
On Tue, Aug 06, 2019 at 10:58:53PM +0000, brian m. carlson wrote:
Show 19 quoted lines
> On 2019-08-06 at 14:38:30, Jeff King wrote:
> > It's hard for scripted uses of rev-list, etc, to avoid option injection
> > from untrusted arguments, because revision arguments must come before
> > any "--" separator. I.e.:
> > 
> >   git rev-list "$revision" -- "$path"
> > 
> > might mistake "$revision" for an option (with rev-list, that would make
> > it an error, but something like git-log would default to HEAD).
> > 
> > This series provides an alternative to "--" to stop option parsing
> > without indicating that further arguments are pathspecs.
> 
> Sorry, I hadn't had a chance to look at this series in depth, but I was
> wondering: could we not just accept two separate "--" arguments, and if
> there are two of them, interpret the first with the traditional meaning
> and the second with the Git-specific meaning? That would be much more
> intuitive for folks, although I suspect it would take a little more work
> in the options parser.

That also crossed my mind, but I think it opens up some complicated corner cases. For instance, if I'm parsing left-to-right and see "--", how do I know which separator it is meant to be? I think the only rule that makes sense is that you must have two "--", like:

  git rev-list [options] -- [revs] -- [paths]

but that means parsing the whole thing before we can interpret any of it. What kinds of tricks can an attacker play by putting "--" in the revs or paths areas? E.g., what does this mean:

  # expanded from "git rev-list -- $revs -- $paths"
  git rev-list -- --foo -- -- --bar --

I think if we at least choose the left-most "--" as the official end-of-options then they can't inject an option (they can only inject a rev as a path). I guess that's the same as with --end-of-options. But it somehow feels less clear to me than a separate marker.

It also doesn't allow this:
  # allow paths and revs, with optional separator, but no more options
  git rev-list --end-of-options "$@"
though I'm not sure whether anybody cares.
-Peff
Previous: brian m. carlsonNext: brian m. carlson
Message 13 of 16 in “--end-of-options marker”
  1. 0/3 --end-of-options markerJeff King, Aug 6, 2019
  2. 1/3 revision: allow --end-of-options to end option parsingJeff King, Aug 6, 2019
  3. 2/3 parse-options: allow --end-of-options as a synonym for "--"Jeff King, Aug 6, 2019
  4. 3/3 gitcli: document --end-of-optionsJeff King, Aug 6, 2019
  5. Junio C HamanoAug 6, 2019
  6. Randall S. BeckerAug 6, 2019
  7. Jeff KingAug 6, 2019
  8. Randall S. BeckerAug 6, 2019
  9. SZEDER GáborAug 6, 2019
  10. Jeff KingAug 8, 2019
  11. Jeff KingAug 6, 2019
  12. brian m. carlsonAug 6, 2019
  13. Jeff KingAug 6, 2019
  14. brian m. carlsonAug 7, 2019
  15. Taylor BlauAug 7, 2019
  16. Jeff KingAug 8, 2019

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.