Compliance nonsense [LWN.net]

Compliance nonsense

Posted Jun 24, 2022 2:31 UTC (Fri) by roguelazer (subscriber, #101286)
Parent article: Whatever happened to SHA-256 support in Git?

I know that I've had to have arduous discussions with several external auditors over why it's "okay" that git uses SHA-1 and why we're not switching to some commercial VCS that doesn't (obviously) use SHA-1; I imagine this is happening to corporations all over the world which are subject to various regulatory regimes with a "no SHA1 or MD5" checklist entry. I'm surprised no big corporation has dumped a bunch of funding into this project to satisfy such auditors.

to post comments

Compliance nonsense

Posted Jun 24, 2022 7:51 UTC (Fri) by epa (subscriber, #39769) [Link] (3 responses)

Or make a quick and dirty fork of git which only uses SHA-256 and isn't backwards compatible or interoperable.

Compliance nonsense

Posted Jun 26, 2022 14:49 UTC (Sun) by jthill (subscriber, #56558) [Link] (2 responses)

Except that exists already, it's just Git. `git init --object-format=sha256` and your repo uses sha256 only and can't talk to sha1 repos. I'd be curious how easily the web frontends' private-server options can be made to use the new object format if they don't have to talk to any poor left-behind sha1 repos either.

As a side note, afaik all known or suspected collision-generating methods require some place to hide gobs of carefully-chosen noise bits in both colliding texts. pdf is a binary format and can hide arbitrary noise. source code can not. There is no possibility that anyone get an engineered source file past even the most cursory code review. The garbage would appear the first time anyone so much as glanced at the diffs.

Compliance nonsense

Posted Jun 28, 2022 11:49 UTC (Tue) by cortana (subscriber, #24596) [Link] (1 responses)

Eagerly awaiting a tool that produces collisions by adding commented ascii art to source code... :)

Compliance nonsense

Posted Jul 15, 2022 15:31 UTC (Fri) by epa (subscriber, #39769) [Link]

That's an interesting point. If the hash function is known to be weak (or you want to hedge against it becoming broken in future) then you could add an extra defence with a 'normalized hash'. If the file looks like C source code then strip out the comments, normalize the whitespace, and perhaps rename all the variables that aren't visible from outside the compilation unit. Then both the original content and the normalized one are hashed separately and both of these go into the final commit id.