On 04/30/2012 11:11 PM, Junio C Hamano wrote:
Michael Haggerty<mhagger@xxxxxxxxxxxx> 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@xxxxxxxxxxxx
http://softwareswirl.blogspot.com/
--
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