Ævar Arnfjörð Bjarmason [off-list ref] 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? ;-)
On Wed, Dec 26 2018, Junio C Hamano wrote:
Ævar Arnfjörð Bjarmason [off-list ref] writes:
quoted
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.
Hi,
Ævar Arnfjörð Bjarmason wrote:
On Wed, Dec 26 2018, Junio C Hamano wrote:
quoted
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? ;-)
Yes, agreed. This is what I was hinting at in [1] with "it's a plain
bug".
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.
Just for the record, as I've already said, I would be strongly against
removing this feature. I know of multiple populations that make use
of it, and removing it would not serve them well.
Changing defaults and documentation is a separate story.
Sincerely,
Jonathan
[1] https://public-inbox.org/git/20181217231452.GA13835@google.com/