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
