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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeff King <peff@xxxxxxxx> 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.

> -- >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@xxxxxxxx>
> ---
>  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--;



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux