Re: [PATCH] sideband: diagnose more incoming packet anomalies

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 27, 2020, 21:38 UTC
Message-ID: <xmqqzh479wor.fsf@gitster.c.googlers.com>
In-Reply-To: <20201027204205.GA643357@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

> Does this patch seem otherwise worth doing?

Yeah.

FWIW, I do not find the "dependency" thing disturbing. sideband is an extension of the pkt-line mechansim, so it is natural that it depends on pkt-line. I'd also be happy if enums, structures and calls defined in both headers are made available by just including one of them (e.g. retire sideband.h, perhaps).

> An alternate patch would be to keep the behavior the same and just
> clarify the code a bit. Something like:

This also looks OK to me from readability's point of view, but it does not as much help the end user who is puzzled as the real thing, I am afraid.

Thanks.

Show 61 quoted lines

> -- >8 --
> Subject: [PATCH] demultiplex_sideband(): clarify corner cases
>
> The size checks in demultiplex_sideband() are a bit subtle and
> confusing:
>
>   - we consider a zero-length packet ("0004") to be a flush packet, even
>     though it's not really one. This is perhaps wrong, but it should
>     never happen in our protocol, and we err on the side of history and
>     leniency. We'll leave a comment indicating that we expect this case.
>
>   - likewise we consider any flush-like packet (e.g., "0001" delim) to
>     be a flush. I didn't confirm whether this is necessary for normal
>     protocol usage. It may be for the everything-over-sideband mode
>     introduced by 0bbc0bc574 ({fetch,upload}-pack: sideband v2 fetch
>     response, 2019-01-16). Likewise let's leave a comment.
>
>   - we check for "len < 1" to see if there's no sideband designator.
>     That's confusing, because we already covered the "len == 0" case.
>     What is interesting is the "len < 0" case. But that's not a missing
>     sideband designator, but rather an error or EOF from the pkt-line
>     code. This should never happen, though, because our callers instruct
>     pkt-line to die() on EOF anyway. So let's make it more obvious
>     that we're looking for a negative value here, and consider it a
>     BUG() in the caller to pass us garbage.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
>  sideband.c | 15 ++++++++-------
>  1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/sideband.c b/sideband.c
> index 0a60662fa6..6ba1925614 100644
> --- a/sideband.c
> +++ b/sideband.c
> @@ -130,17 +130,18 @@ int demultiplex_sideband(const char *me, char *buf, int len,
>  			suffix = DUMB_SUFFIX;
>  	}
>  
> +	if (len < 0)
> +		BUG("error/eof packet passed to demultiplex_sideband");
> +
>  	if (len == 0) {
> +		/*
> +		 * we treat all flush-like packets (flush, delim, etc) and even
> +		 * empty data packets as a flush
> +		 */
>  		*sideband_type = SIDEBAND_FLUSH;
>  		goto cleanup;
>  	}
> -	if (len < 1) {
> -		strbuf_addf(scratch,
> -			    "%s%s: protocol error: no band designator",
> -			    scratch->len ? "\n" : "", me);
> -		*sideband_type = SIDEBAND_PROTOCOL_ERROR;
> -		goto cleanup;
> -	}
> +
>  	band = buf[0] & 0xff;
>  	buf[len] = '\0';
>  	len--;