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

Re: [PATCH 1/1] rebase -r: let `label` generate safer labels

From
brian m. carlson <sandals@crustytoothpaste.net>
Date
Sep 2, 2019, 20:12 UTC
Message-ID
<20190902201230.GG11334@genre.crustytoothpaste.net>
In-Reply-To
<xmqq5zmav9ej.fsf@gitster-ct.c.googlers.com>
On 2019-09-02 at 18:29:56, Junio C Hamano wrote:
Show 16 quoted lines
> Phillip Wood <phillip.wood123@gmail.com> writes:
> 
> > Being picking I'll point out that ':' is not a valid in refs
> > either. Looking at
> > https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file I
> > think only " and | are not allowed on NTFS/FAT but are valid in refs
> > (see the man page for git check-ref-format for all the details). So
> > the main limitation is actually what git allows in refs.
> 
> Yeah, trying to use the contents of the log message without
> sufficient sanitization is looking for trouble.
> 
> >>   		for (p1 = label.buf; *p1; p1++)
> >> -			if (isspace(*p1))
> >> +			if (!(*p1 & 0x80) && !isalnum(*p1))
> >>   				*(char *)p1 = '-';

While we're thinking of things that could go wrong, note that it's also possible for the commit message to contain non-UTF-8 characters (if the user is using a non-UTF-8 encoding), which will cause sadness on Windows and macOS. Non-Mac Unix systems aren't a problem here, but then again, they aren't the reason for this patch.

Show 9 quoted lines
> > I'm sightly concerned that this opens the possibility for unexpected
> > effects if two different labels get sanitized to the same string. I
> > suspect it's unlikely to happen in practice but doing something like
> > percent encoding non-alphanumeric characters would avoid the problem
> > entirely.
> 
> I see there are "lets make sure it is unique by suffixing "-%d" in
> other codepaths; would that help if this piece of code yields a
> label that is not unique?

I was thinking the same thing. Since we're being much less lenient on what's allowed (which is fine), we're at increased risk for collision.

-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204
Previous: Junio C HamanoNext: Philip Oakley
Message 5 of 22 in “Make git rebase -r's label generation more resilient”
  1. 0/1 Make git rebase -r's label generation more resilientJohannes Schindelin via GitGitGadget, Sep 2, 2019
  2. 1/1 rebase -r: let `label` generate safer labelsMatt R via GitGitGadget, Sep 2, 2019
  3. Phillip WoodSep 2, 2019
  4. Junio C HamanoSep 2, 2019
  5. brian m. carlsonSep 2, 2019
  6. Philip OakleySep 2, 2019
  7. Johannes SchindelinSep 3, 2019
  8. Junio C HamanoSep 3, 2019
  9. Matt RogersSep 3, 2019
  10. Johannes SchindelinSep 2, 2019
  11. Junio C HamanoSep 3, 2019
  12. Johannes SchindelinNov 18, 2019
  13. 0/2 Make git rebase -r's label generation more resilientJohannes Schindelin via GitGitGadget, Nov 17, 2019
  14. 2/2 rebase -r: let `label` generate safer labelsMatthew Rogers via GitGitGadget, Nov 17, 2019
  15. 1/2 rebase-merges: move labels' whitespace mangling into `label_oid()`Johannes Schindelin via GitGitGadget, Nov 17, 2019
  16. Junio C HamanoNov 18, 2019
  17. sequencer: handle rebase-merge for "onto" messageDanh Doan, Nov 18, 2019
  18. sequencer: handle rebase-merges for "onto" messageDoan Tran Cong Danh, Nov 18, 2019
  19. Johannes SchindelinNov 18, 2019
  20. Junio C HamanoNov 21, 2019
  21. Johannes SchindelinNov 18, 2019
  22. Philip OakleySep 2, 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.