Robin Rosenberg <robin.rosenberg.lists@xxxxxxxxxx> wrote: > onsdag 09 september 2009 20:55:39 skrev "Adam W. Hawks" <awhawks@xxxxxxxxxxx>: > > 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html