From: A Large Angry SCM <gitzilla@gmail.com>
To: Michael Haggerty <mhagger@alum.mit.edu>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>, cmn@elego.de
Subject: Re: [PATCH 0/6] Improved infrastructure for refname normalization
Date: Fri, 09 Sep 2011 10:06:53 -0400 [thread overview]
Message-ID: <4E6A1D7D.6050602@gmail.com> (raw)
In-Reply-To: <1315568778-3592-1-git-send-email-mhagger@alum.mit.edu>
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
next prev parent reply other threads:[~2011-09-09 14:07 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-09 11:46 [PATCH 0/6] Improved infrastructure for refname normalization Michael Haggerty
2011-09-09 11:46 ` [PATCH 1/6] Change bad_ref_char() to return a boolean value Michael Haggerty
2011-09-09 11:46 ` [PATCH 2/6] git check-ref-format: add options --onelevel-ok and --refname-pattern Michael Haggerty
2011-09-09 11:46 ` [PATCH 3/6] Change check_ref_format() to take a flags argument Michael Haggerty
2011-09-09 11:46 ` [PATCH 4/6] Add a library function normalize_refname() Michael Haggerty
2011-09-09 11:46 ` [PATCH 5/6] Do not allow ".lock" at the end of any refname component Michael Haggerty
2011-09-09 11:46 ` [PATCH 6/6] Add a REFNAME_ALLOW_UNNORMALIZED flag to check_ref_format() Michael Haggerty
2011-09-09 23:30 ` Junio C Hamano
2011-09-10 4:04 ` Michael Haggerty
2011-09-09 14:06 ` A Large Angry SCM [this message]
2011-09-09 15:33 ` [PATCH 0/6] Improved infrastructure for refname normalization Michael Haggerty
2011-09-09 17:57 ` Junio C Hamano
2011-09-10 3:31 ` Michael Haggerty
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E6A1D7D.6050602@gmail.com \
--to=gitzilla@gmail.com \
--cc=cmn@elego.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=mhagger@alum.mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.