Re: [PATCH v2 09/11] serve: reject bogus v2 "command=ls-refs=foo"
- From
Eric Sunshine <sunshine@sunshineco.com>
- Date
- Sep 15, 2021, 05:09 UTC
- Message-ID
- <CAPig+cQNipgVwYZw3r2nQMZ_AOOsFEp1=MgEdmZcdAPnFE7gZA@mail.gmail.com>
- In-Reply-To
- <YUE1ym1dALRQLztq@coredump.intra.peff.net>
On Tue, Sep 14, 2021 at 7:52 PM Jeff King <peff@peff.net> wrote:
Show 21 quoted lines
> When we see a line from the client like "command=ls-refs", we parse > everything after the equals sign as a capability, which we check against > our capabilities table. If we don't recognize the command (e.g., > "command=foo"), we'll reject it. But we use the same parser that checks > for regular capabilities like "object-format=sha256". And so we'll > accept "ls-refs=foo", even though everything after the equals is bogus, > and simply ignored. > > This isn't really hurting anything, but the request does violate the > spec. Let's tighten it up to prevent any surprising behavior. > > Signed-off-by: Jeff King <peff@peff.net> > --- > diff --git a/t/t5701-git-serve.sh b/t/t5701-git-serve.sh > @@ -72,6 +72,16 @@ test_expect_success 'request invalid command' ' > +test_expect_success 'requested command is command=value' ' > + test-tool pkt-line pack >in <<-\EOF && > + command=ls-refs=whatever > + object-format=$(test_oid algo) > + 0000 > + EOF
This here-doc uses <<-\EOF yet (presumably) expects $(test_oid algo) to be expanded. I'm guessing that you meant <<-EOF but never noticed...
> + test_must_fail test-tool serve-v2 --stateless-rpc 2>err <in &&
... because of this test_must_fail().
> + grep invalid.command.*ls-refs=whatever err > +'