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

Re: [ JGIT ] incompatiblity found in DirCache

From
Shawn O. Pearce <spearce@spearce.org>
Date
Sep 11, 2009, 15:05 UTC
Message-ID
<20090911150522.GI1033@spearce.org>
In-Reply-To
<200909092311.07145.robin.rosenberg.lists@dewire.com>
Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
Show 13 quoted lines
> onsdag 09 september 2009 20:55:39 skrev "Adam W. Hawks" <awhawks@writeme.com>:
> > When using the DirCache interface to the index you can create a
> > invalid/corrupt tree for git 1.6.5.
> > 
> > The problem seems to be you can add a path to the index that starts
> > with a "/" and DirCache creates a entry with a mode but no path.
> > This causes git 1.6.5 to fail with a corrupt tree.
> 
> I think there are more ways of entering bad stuff. Preventing a
> deliberate programmatic creation of invalid trees is probably not
> the most important thing, but then again, validating the data to
> prevent e.g. the EGit plugin from doing it by mistake due to bugs
> could probably be worthwhile.

We already check for and fail fast on a 0 mode in DirCache, as this mode is also not valid in the index, or in a git tree.

We should be doing the same thing for an empty path name. "a//b" is not a valid path in the index, as "" is not a valid tree entry path. For the same reason, "/a" is not a valid path in the index.

Unfortunately our API also allows you to try and create a name of "a\u0000b", which is a valid Java string, but will create a corrupt tree. \u0000 in a name with more than 4095 bytes will also create a corrupt index (shorter strings are semi-valid because shorter strings use a Pascal like string format, and longer ones use a C like string format). Though C git is unable to access a path whose name contains "\u0000", no matter how long the string is.

I think we should try a bit harder in DirCache to prevent these sorts of really bad entries from being constructed by application code. Yes, applications should not do this, but I think the library also should not write known bogus trash to the disk and claim it is OK.

I'll try to work up a patch for this today.
-- 
Shawn.
Previous: Robin Rosenberg
Message 3 of 3 in “[ JGIT ] incompatiblity found in DirCache”
  1. Adam W. HawksSep 9, 2009
  2. Robin RosenbergSep 9, 2009
  3. Shawn O. PearceSep 11, 2009

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.