Re: [PATCH v20 43/48] refs.c: move the check for valid refname to lock_ref_sha1_basic
- From
Jonathan Nieder <jrnieder@gmail.com>
- Date
- Aug 20, 2014, 17:49 UTC
- Message-ID
- <20140820174914.GE20185@google.com>
- In-Reply-To
- <CAL=YDW=zmqwjLzjWYLGCjwb_aQTofTJ-CrmPgoq3KKJjfHR3XQ@mail.gmail.com>
Hi,
Ronnie Sahlberg wrote:
> On Wed, Aug 20, 2014 at 7:52 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
Show 10 quoted lines
>> 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