On Wed, Dec 26 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
>
>> The genreal ways I see forward from that are:
>>
>> A) Say that v2 has a security issue and that this is a feature that
>> works in some circumstances, but given Jeff's explanation here we
>> should at least improve our "SECURITY" docs to be less handwaivy.
>>
>> B) Improve security docs, turn uploadpack.allowAnySHA1InWant=true on by
>> default, allow people to turn it off.
>>
>> C) Like B) but deprecate
>> uploadpack.allow{Tip,Reachable,Any}SHA1InWant=false. This is my
>> patch upthread
>>
>> D-Z) ???
>>
>>
>> I'm not set on C), and yeah it's probably overzelous to just rip the
>> thing out, but then what should we do?
>
> Hmph. The other overzealous thing you could do is to strenthen A
> and "fix" the security issue in v2? Which letter comes before A in
> the alphabet? ;-)
Sure, but that being useful is predicated on this supposed security
mechanism being useful and not just security-through-obscurity, as noted
in side-threads I don't think we have a convincing argument either way
(and the one we do have is more on the "it's not secure" side).
Of course we had that with v1 all along, but now that v2 is in released
versions and in this insecure mode, we have a reason to closely look at
whether we need to be issuing security releases, or doubling down on the
"SECURITY" wording in git-fetch and then not carrying the mode forward.
