Re: [PATCH v2 1/8] uploadpack.txt: document implication of `uploadpackfilter.allow`

[Jeff King <peff@peff.net>]

On Mon, Mar 15, 2021 at 02:14:31PM +0100, Patrick Steinhardt wrote:

> When `uploadpackfilter.allow` is set to `true`, it means that filters
> are enabled by default except in the case where a filter is explicitly
> disabled via `uploadpackilter.<filter>.allow`. This option will not only
> enable the currently supported set of filters, but also any filters
> which get added in the future. As such, an admin which wants to have
> tight control over which filters are allowed and which aren't probably
> shouldn't ever set `uploadpackfilter.allow=true`.
> 
> Amend the documentation to make the ramifications more explicit so that
> admins are aware of this.

It might help to guide the admin a bit more here. What are we really
worried about? Probably that an expensive filter would be added that
would make an admin with a public-facing server unhappy.

Maybe we should be more explicit about our recommendations, like:

  This defaults to `true` for historical reasons, but that includes
  expensive-to-compute filters (both existing ones like `sparse`, but
  also future ones). A safer value is to set this to `false` and
  mark individual filters as allowed.

But then of course somebody wonders which set are expensive and which
ones are not. And really, "expensive" here is not that expensive. It is
"do not support bitmaps".

So I wonder if this concern is overblown in the first place. People who
care about using only bitmap-supported filters probably already set this
to "false". And vaguely calling things "expensive" is probably being
overly scary. But in that case, I'm not sure we even need to add a
reminder that future ones will also be enabled (OTOH, I do not mind it
so much; it is encouraging people to set this to false and mark
individual ones as allowed).

-Peff