Re: [PATCH] create_ref_entry(): move check_refname_format() call to callers
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Apr 30, 2012, 21:11 UTC
- Message-ID
- <7vsjfkexh1.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <4F9EF60D.8030301@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
Show 5 quoted lines
> 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)?
The UI layer may place additional restrictions to the source data used to eventually lead to a ref creation (e.g. your updated "git branch" may forbid you to create a branch with the name of an existing tag, perhaps), but after passing its check, the API to create a new ref will do mandatory "check-ref-format" check.