From: Jeff King <peff@peff.net>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
git@vger.kernel.org, Jonathan Tan <jonathantanmy@google.com>,
Jeff Hostetler <jeffhost@microsoft.com>
Subject: Re: [RFC/PATCH] upload-pack: disable object filtering when disabled by config
Date: Thu, 29 Mar 2018 17:55:02 -0400 [thread overview]
Message-ID: <20180329215502.GK2939@sigill.intra.peff.net> (raw)
In-Reply-To: <20180328203303.GA260688@aiede.svl.corp.google.com>
On Wed, Mar 28, 2018 at 01:33:03PM -0700, Jonathan Nieder wrote:
> When upload-pack gained partial clone support (v2.17.0-rc0~132^2~12,
> 2017-12-08), it was guarded by the uploadpack.allowFilter config item
> to allow server operators to control when they start supporting it.
>
> That config item didn't go far enough, though: it controls whether the
> 'filter' capability is advertised, but if a (custom) client ignores
> the capability advertisement and passes a filter specification anyway,
> the server would handle that despite allowFilter being false.
>
> This is particularly significant if a security bug is discovered in
> this new experimental partial clone code. Installations without
> uploadpack.allowFilter ought not to be affected since they don't
> intend to support partial clone, but they would be swept up into being
> vulnerable.
>
> Simplify and limit the attack surface by making uploadpack.allowFilter
> disable the feature, not just the advertisement of it.
Great catch. If I understand correctly, this is an issue in the 2.17.0
release candidates. Is this worth delaying the release?
It's a funny situation. The presence of a security bug is theoretical
here, so nobody _should_ need to care, and this is just hardening. But
it does make me a little nervous, given the experimental-ness of the new
feature.
-Peff
next prev parent reply other threads:[~2018-03-29 21:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-28 20:33 [RFC/PATCH] upload-pack: disable object filtering when disabled by config Jonathan Nieder
2018-03-28 22:12 ` Junio C Hamano
2018-03-29 13:47 ` Jeff Hostetler
2018-03-29 21:55 ` Jeff King [this message]
2018-03-29 22:03 ` Jonathan Nieder
2018-03-29 22:17 ` Jeff King
2018-03-29 22:31 ` Junio C Hamano
2018-03-30 1:45 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180329215502.GK2939@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jeffhost@microsoft.com \
--cc=jonathantanmy@google.com \
--cc=jrnieder@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).