Re: [PATCH] push: do not turn --delete '' into a matching push

[Jeff King <peff@peff.net>]

On Tue, Feb 23, 2021 at 03:13:32PM -0800, Junio C Hamano wrote:

> When we added a syntax sugar "git push remote --delete <ref>" to
> "git push" as a synonym to the canonical "git push remote :<ref>"
> syntax at f517f1f2 (builtin-push: add --delete as syntactic sugar
> for :foo, 2009-12-30), we weren't careful enough to make sure that
> <ref> is not empty.
> 
> Blindly rewriting "--delete <ref>" to ":<ref>" means that an empty
> string <ref> results in refspec ":", which is the syntax to ask for
> "matching" push that does not delete anything.
> 
> Worse yet, if there were matching refs that can be fast-forwarded,
> they would have been published prematurely, even if the user feels
> that they are not ready yet to be pushed out, which would be a real
> disaster.
> 
> Noticed-by: Tilman Vogel <tilman.vogel@web.de>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> 
>  * So this time with an obvious test.  It is somewhat surprising
>    that this has been left unnoticed for the past 10 years.

Thanks, this looks like the obviously correct fix. I'm not too surprised
that nobody noticed. You have to add quoting to get an empty-string
argument in shell, and the non-delete case does notice and complain.

I did wonder if this was related to recent refactoring around the
refspec code (like negative refspecs), but I think this function is
independent of that anyway. Thanks for tracking down the original
culprit.

> diff --git a/builtin/push.c b/builtin/push.c
> index 03adb58602..194967ed79 100644
> --- a/builtin/push.c
> +++ b/builtin/push.c
> @@ -115,7 +115,7 @@ static void set_refspecs(const char **refs, int nr, const char *repo)
>  			else
>  				refspec_appendf(&rs, "refs/tags/%s", ref);
>  		} else if (deleterefs) {
> -			if (strchr(ref, ':'))
> +			if (strchr(ref, ':') || !*ref)
>  				die(_("--delete only accepts plain target ref names"));
>  			refspec_appendf(&rs, ":%s", ref);
>  		} else if (!strchr(ref, ':')) {

Just wondering if there are other similar bugs lurking:

  - could we see other strings that aren't empty, but also aren't plain
    target ref names? E.g., other punctuation like a "^" negative
    refspec? I guess that would produce ":^", which the refspec code
    will catch.

  - likewise, do any of these other else clauses blindly pass around an
    empty string? Yes, the final one does, but we catch it later in the
    refspec code.

So I think it really is this "blindly prepend a colon" part that is the
real bug. Anything else would create a nonsense refspec that will be
caught by the refspec code.

-Peff