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)? 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. -- 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