Re: [PATCH v3 5/6] doc hash-function-transition: move rationale upwards

Ævar Arnfjörð Bjarmason [off-list ref] writes:

I missed version 2 of this. I don't think it's an improvement to
completely remove the description of us using sha1collisiondetection by
default, i.e. effectively revert 5988eb631a3 (doc
hash-function-transition: clarify what SHAttered means, 2018-03-26)
...
I can see how my comment on v1 could have been read like that. FWIW I
didn't mean remove the whole thing, but that I don't think it adds much
value to our description of how we use SHA-1 to go into the level of
detail of mentioning several researchers by name, there's Wikipedia for
that.

True.

I think what we should instead do is have some brief summary of the
vulnerabilities and how they're impacting git.

I am not sure.

Maybe I'm barking up the wrong tree here, and what I'm describing should
be in a "man 5 gitsecurity" or something.

I agree with your that it belongs to some other document, but not
here, where the primary thing is to outline how the migration will
go, and the part we are seeing is merely giving a background story.
At this point in time, readers would not have to learn the details
from this document.  People already know that we are not happy with
SHA-1 and is on our way to migrate to SHA-256.

But anyway, I think it adds a lot of value to somewhere have not just
what amounts to "sha-1 sucks, see research papers", but to have some
brief human-readable summary of what the practical impact is on users.

Yeah.  I think Thomas has in [v3 5/6] gives our readers about the
right level of details.  If I were to change anything, I'd do "but
SHA-1 is {+considered+} still weak."

In 2018 it was true that sha1collisiondetection was mitigating the known
attack in practice, and that's also true about this new attack[1] (maybe
there's others I missed ...).

Then there's the fact that we don't *just* rely on SHA-1, but e.g. the
"don't re-write objects we have already". So as a practical attack on
someone using git ...

Oh, and the attacks currently all seem to require file formats like JPEG
or PDF for anything practical, i.e. being able to spew in lots of
arbitrary data into some data segment, as opposed to e.g. creating a
program that compiles.

None of this is meant as some overall defense of SHA-1, just that most
of our users aren't security researchers, and will be helped by a
summary of how this system they're using using SHA-1, and having read
that it's "broken" or "believed to be weak" translates to a threat to
them in practice.

All of the above are good thing for somebody to write about, but I
am not sure it fits well in the context of this document.  This is
primarily about how the migration should go, and the target audience
is those of us who are already committed to the plan.  The backstory
on how the plan came about makes a nice introductory reading but it
would not be productive to spend too much bits for the purpose of the
document and its target audience, I would think.

Thanks.