Hi,
I admittedly did not go so far as to track down test objects with the same
SHA-1 hash and construct an experiment. But I couldn't see any way where
git fsck could *not* detect this problem unless I'm wrong that it
recalculates all the hashes, and I'm fairly sure I'm not wrong about that.
As a side-note, at SUSE, we would like to move from an internal SCM for
package management to git based. One of the stumbling blocks was exactly
SHA1.
For purposes of source code management and revisions, it's probably
fine. Like many have said already, it's fine to store source code with
SHA1 if you are planning on looking at diffs, between revisions before
you trust it.
On the other hand, if you are going to put any sort of trust into the
system, it's impossible to trust SHA1. It's being phased out in all
forms[1]. Currently, it takes about $50k to get a collision AFAIK.
That's rich for me, but for nation state? And from the standpoint of
certifications, impossible.
The bottom line is, GPG uses SHA256 or SHA512 for signing a message. But
when this message is SHA1 ... that signature is practically useless from
a security standpoint. At very least, it's *severely* weakened.
We are now trying to use SHA256 repos with Gitea -- I've added SHA256
support there last year and currently it "just works". Forgejo (gitea
fork) backported this support already too.
IFF moving to SHA256 repos is impossible because no one cares to fix it,
then at very least these tags must use additional hashing for purposes
of tree verification. Bitcoin sources seems to use this approach. [2]
Then the code can be verified against this more secure hash on upload.
Actually, this approach allows use multiple hashes similar to .dsc files.
Best,
- Adam
[1] -
https://www.nist.gov/news-events/news/2022/12/nist-retires-sha-1-cryptographic-algorithm
[2] - https://github.com/bitcoin/bitcoin/pull/9871
