On 09/09/2011 07:46 AM, Michael Haggerty wrote:
As a prerequisite to storing references caches hierarchically (itself needed for performance reasons), here is a patch series to help us get refname normalization under control. The problem is that some UI accepts unnormalized reference names (like "/foo/bar" or "foo///bar" instead of "foo/bar") and passes them on to library routines without normalizing them. The library, on the other hand, assumes that the refnames are normalized. Sometimes (mostly in the case of loose references) unnormalized refnames happen to work, but in other cases (like packed references or when looking up refnames in the cache) they silently fail. Given that refnames are sometimes treated as path names, there is a chance that some security-relevant bugs are lurking in this area, if not in git proper then in scripts that interact with git.
Why can't the library do the normalization instead of expecting every other component that deals with reference names having to do it for the library?
[...]
* Forbid ".lock" at the end of any refname component, as directories with such names can conflict with attempts to create lock files for other refnames.
I find this overly restrictive. If you need to create a lock based on a reference name or component, use a name for the lock object that starts with one of the characters that reference names or components are already forbidden from starting with.
Gitzilla -- 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