On Wed, Aug 20, 2014 at 10:49 AM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > Hi, > > Ronnie Sahlberg wrote: >> On Wed, Aug 20, 2014 at 7:52 AM, Michael Haggerty <mhagger@xxxxxxxxxxxx> 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? Good idea! I will add such a check using the iterator. That means that "we can git branch -D anything that shows up in the iterator regardless if the ref is badly named or unresolvable" which sounds like fairly sane semantics. Thanks! Ronnie -- 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