Compliance nonsense [LWN.net]

Compliance nonsense

Posted Jun 24, 2022 7:51 UTC (Fri) by epa (subscriber, #39769)
In reply to: Compliance nonsense by roguelazer
Parent article: Whatever happened to SHA-256 support in Git?

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

to post comments

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.