Re: check_refname_format allows refs with components that begin with -, even though `git tag` does not

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 10, 2020, 20:09 UTC
Message-ID: <xmqqd00l6kj0.fsf@gitster.c.googlers.com>
In-Reply-To: <c926193b-a328-7562-6d4b-1ab2765c8cca@invisiblethingslab.com>

"Demi M. Obenour" <athena@invisiblethingslab.com> writes:

> If I try to create a Git tag with a name beginning with `-`,
> Git complains.  However, Git does not check that a repository does
> not have tags containing `-`.

This is quite deliberate. The command line parser of "git checkout" and friends long lacked way to say "switch to THAT BRANCH whose name begins with a hyphen" etc., and preventing tags and branches whose name begins with a hyphen from created at the Porcelain level was a way to stop users from hurting themselves.

These funny names are supported at the plumbing level primarily because we have historically allowed them and suddenly forbidding their use would break existing repository. A secondary reason is to have a way to learn the current value of and then remove them, so people with these funnily named branches and tags can "rename" them.

> This almost led to a vulnerability in the QubesOS `verify-git-tag`
> script.

Scripts need to be careful about their inputs, period.

> The best idea I had for a fix is to print names beginning with `-`
> using the fully-qualified form, such as "refs/tags/-a".  Also, `--`
> is used as a delimiter in many commands, and can’t be escaped,
> so disallowing it might be a good idea.

I do not think there is anything to fix.

Command line parsers of some commands may have to learn how to disambiguate such a strangely named tags and branches, though. Some commands do not know --end-of-options convention, for example.

Thanks.

[Further reading]

https://lore.kernel.org/git/7v62pjo4km.fsf@alter.siamese.dyndns.org/ https://lore.kernel.org/git/7vsk262vla.fsf@alter.siamese.dyndns.org/