Re: input validation in receive-pack

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Jan 2, 2008, 05:01 UTC
Message-ID: <alpine.LNX.1.00.0801012353580.13593@iabervon.org>
In-Reply-To: <7vzlvp3oya.fsf@gitster.siamese.dyndns.org>

On Tue, 1 Jan 2008, Junio C Hamano wrote:

Show 17 quoted lines

> mkoegler@auto.tuwien.ac.at (Martin Koegler) writes:
> 
> > In the update code path, the check is done in refs.c:
> > | struct ref_lock *lock_any_ref_for_update(const char *ref, const unsigned char *old_sha1, int flags)
> > | {
> > |         if (check_ref_format(ref) == -1)
> > |                 return NULL;
> > |         return lock_ref_sha1_basic(ref, old_sha1, flags, NULL);
> > | }
> >
> > check_ref_format may also return -2 (less than two name levels) and -3
> > (* at the end), which are ignored. Is it really intended, that
> > receive-pack can create such refs.
> 
> Misconversion in 8558fd9ece4c8250a037a6d5482a8040d600ef47 that
> changed check_ref_format() without looking at what its callers
> are checking, I think.

When I got to it, it was already accepting -2. It clearly shouldn't accept -3 (and I don't know why I missed it; I was probably misinterpreting the original logic there.

	-Daniel
*This .sig left intentionally blank*