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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Adam Majer <[email protected]> writes:

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.

Is that a collision against generic SHA1, or a collision against SHA1DC as
is used in Git?

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.

The complaint I am always going to make about claims like this is that
this is a very absolute statement to make about the properties of a system without additional context. This has some merit in providing people with simple rules of thumb to avoid tricky morasses that there is no need to
trudge through, but rules of thumb are by definition sacrificing accuracy
for simplicity. The context sometimes matters a great deal. Ask any
Kerberos person about the constant carping about SHA1 in the Kerberos
protocol, where it is used in ways that make hash collisions irrelevant.

For example, there are a lot of situations in which the SHA1 weaknesses
don't matter in Git because there is no realistic opportunity for an
attacker to substitute an object with the same SHA1 hash. Is it complex
to be certain that's the case? Yes. Is there some constant risk that you
may start in such a situation and accidentally slip into a situation that
is vulnerable to attack? Yes. Is it better to avoid SHA1 entirely so
that you don't have to think about it? Absolutely.

Is it correct to say, as an absolute statement, that a signature over a
SHA1 hash is practically useless? No, it is not. This is far too strong
of a claim. You have to analyze the attack first: what does the attacker
have to do to substitute an underlying colliding object in such a way that
the signature provides an incorrect promise? In some cases, this is a
very real attack. In other cases, it is not.

In the case of Git in particular, the provenance of the signed Git tree is relevant. In many usage scenarios, you are obtaining the Git tree from
some other service or location that is at least partly trusted, which
makes a practical attack via SHA1 collisions considerably harder. Would
it be better to have a signature that is completely independent of
provenance so that you don't have to think about this at all? Yes,
absolutely. But the real world is full of trade offs.

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.

This is excellent, and I hope progress on this front continues. Debian is effectively blocked on adopting SHA256 hashes for most of our Git
repositories until GitLab adopts them. (That isn't the only obstacle, but
it's probably the biggest one.)

Analyzing SHA1 collision properties is quite annoying and tedious and I
would love to stop having to do it by instead using a hash with better
security properties everywhere. I hope the Git community can find a way
to complete their migration. I am worried about some of the choices they
made about how to do the migration (usually it's best practice to add
general hash agility when fixing this type of issue), but I am not part of
that development community and I'm sure they had their reasons.

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.

I consider it an ethical obligation as someone who works in security to
object whenever people make these types of absolute statements about
security properties. Security is almost always a trade off. You can
usually get more security by trading off functionality, up to the obvious
end point of securing a computer by turning it off. The best point to
occupy on that trade-off curve is a hard question that always involves
more factors than only security.

--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/7/24 21:53, Russ Allbery wrote:

Adam Majer <[email protected]> writes:

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.

I consider it an ethical obligation as someone who works in security to object whenever people make these types of absolute statements about
security properties. Security is almost always a trade off. You can
usually get more security by trading off functionality, up to the obvious
end point of securing a computer by turning it off. The best point to
occupy on that trade-off curve is a hard question that always involves
more factors than only security.

It was not an absolute statement, but simply a consequence where I tend
to trust NIST recommendation over handwaving arguments. This is
especially true since I'm no cryptographer and have to rely on other
experts for these recommendations.

Furthermore, did you read what was written in the Bitcoin repo link?
It's simply adding a hash to the signed tag. Since this proposal here
for push-to-upload is to use a script to generate the tag anyway, adding additional hash to the message is kind of a "no-brainer" --- it doesn't
cost anything!

Anyway, I've been forwarded this commit in git upstream recently.

https://github.com/git/git/commit/6ccf041d1d73d69d05118f739c80f83c86caf0d6

Best,
- Adam

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Adam Majer <[email protected]> writes:

On 7/7/24 21:53, Russ Allbery wrote:

I consider it an ethical obligation as someone who works in security to
object whenever people make these types of absolute statements about
security properties. Security is almost always a trade off. You can
usually get more security by trading off functionality, up to the
obvious end point of securing a computer by turning it off. The best
point to occupy on that trade-off curve is a hard question that always
involves more factors than only security.

It was not an absolute statement, but simply a consequence where I tend
to trust NIST recommendation over handwaving arguments. This is
especially true since I'm no cryptographer and have to rely on other
experts for these recommendations.

That makes very good sense to me. Since you don't have expertise in this field, that's exactly what I would recommend you do. That is definitely
the safest approach.

Since I do have expertise in this area, my analysis was more complex than trying to extrapolate from NIST guidance.

Furthermore, did you read what was written in the Bitcoin repo link?
It's simply adding a hash to the signed tag. Since this proposal here
for push-to-upload is to use a script to generate the tag anyway, adding additional hash to the message is kind of a "no-brainer" --- it doesn't
cost anything!

It does cost something: it requires custom code and local configuration
and requires us to use Git differently than everyone else uses Git. You
may or may not care about that cost, but it's a cost.

I didn't get into this because I think it's beside the point, but since
you're asking explicitly: I am also quite dubious of that specific
approach because it's adding an additional hash to only one specific type
of Git object, piecemeal, in a helper script that seems to only be used by
that one repository (and which they seem to have subsequently dropped).
If we're going to add richer hashes in a custom layer on top of Git, we
should use git-evtag or some other similarly comprehensive solution that
has thought through all of the implications, not try to apply hacks and bandaids like that.

git-evtag was discussed earlier, so I won't go into the arguments there
again.

Anyway, I've been forwarded this commit in git upstream recently.

https://github.com/git/git/commit/6ccf041d1d73d69d05118f739c80f83c86caf0d6

Great! Hopefully this will mean GitLab will add support in the near
future.

--
Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)