Re: [PATCH 0/6] Improved infrastructure for refname normalization

From: A Large Angry SCM <gitzilla@gmail.com>
Date: Sep 9, 2011, 14:06 UTC
Message-ID: <4E6A1D7D.6050602@gmail.com>
In-Reply-To: <1315568778-3592-1-git-send-email-mhagger@alum.mit.edu>

On 09/09/2011 07:46 AM, Michael Haggerty wrote:

Show 14 quoted lines

> 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