Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> 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.
