Re: [PATCH] create_ref_entry(): move check_refname_format() call to callers
- From
Michael Haggerty <mhagger@alum.mit.edu>
- Date
- May 2, 2012, 15:38 UTC
- Message-ID
- <4FA154DC.1060607@alum.mit.edu>
- In-Reply-To
- <7vsjfkexh1.fsf@alter.siamese.dyndns.org>
On 04/30/2012 11:11 PM, Junio C Hamano wrote:
Show 12 quoted lines
> Michael Haggerty<mhagger@alum.mit.edu> writes: > >> For example, have all of the following code paths been audited to make >> sure that they cannot introduce class (3) refnames into a repository >> (including via symbolic refs with class (3) targets) even in the face >> of a malicious remote? Can we (and do we want to) rely on this level >> of vigilance being sustained in the future? > > Auditing is one thing, but perhaps the right solution to that issue is to > refactor the existing code so that we have only a handful (preferrably > one) API entry point that is used to create a new ref (not to be confused > with create_ref_entry(), which is not necessarily about creating a ref)?
Yes, definitely. And more broadly, I want refs.{c,h} to become the *only* mechanism for working with refs.
Michael
-- Michael Haggerty mhagger@alum.mit.edu http://softwareswirl.blogspot.com/