Subject: Re: [PATCH v20 43/48] refs.c: move the check for valid refname to lock_ref_sha1_basic

From: Jonathan Nieder <[email-masked]>
Date: Wed, 20 Aug 2014 10:49:14 -0700

Hi,

Ronnie Sahlberg wrote:
> On Wed, Aug 20, 2014 at 7:52 AM, Michael Haggerty <[email-masked]> wrote:

>> I'm a little worried that abandoning *all* refname checks could open us
>> up to somehow trying to delete a "reference" with a name like
>> "../../../../etc/passwd".  Either such names have to be prohibited
>> somehow, or we have to be very sure that they can only come from trusted
>> sources.
>
> I only set this flag from builtin/branch.c so it should only be used
> when a user runs 'git branch -D' from the command line.
> All other places where we delete branches we should still be checking
> the rename for badness.

Right, this should be safe for 'git branch -D' and 'git update-ref -d'.

But if we wanted to open it up in the future for 'git push --delete',
too, then it would be a way to break out of the repository on hosts where
people use git-shell instead of relying on filesystem permissions.  And
that wouldn't be good.

I think elsewhere git has some checks for "does this pathname fall in
this directory".  Could that be reused here, too, to make sure the
resolved path is under the resolved $GIT_DIR/refs directory?

Alternatively, when a ref being deleted doesn't meet the
'check-ref-format' checks, would it make sense to check that it is one
of the refs you can get by iteration?

Jonathan