Am 2021-10-13 um 12:10 schrieb Mickael Istria:
Hi all,
While I'm investigating into Maven code to allow re-using checksums of
Maven artifacts when "p2-ifying" them with Tycho, I noticed only .md5 and
.sha1 seems to be used by Wagon and then also noticed that Maven Central
doesn't contain a "safe" digest signature either.
In this world of supply chain attacks, it could be important to use
stronger algorithms.
Sure, there is PGP signature, but PGP is not intended to verify the
transfer, it's more meant to allow delegating a trust decision from the
artifact to the signer; using it to verify transfer seems overkill, so we'd
rather avoid having to rely on it for transfer verification.
I tried to look on Jira and couldn't see an issue that seems dedicated to
this topic. As the concerns about md5 and sha1 are relatively old, I may
have missed something.
Is there an issue already open to move towards sha256 or should I create a
new one?
Hi Mickael,
this is an overly complex topic I'd like to explain.
First of all Wagon is not involved in this. It does the physical
transport. The payload is opaque. SHA, MD5 aren't verifying any
signatures, it is just calculating a cryptographic hash. For signatures
we have GPG and it should be clear that those checksums are for bitrot
only. Checksums can be faked by anyone, signatures not.
A couple of months ago I have added SHA-2 to Maven Resolver, users
complained (see users@, Dan Tran) that the additional roundtrips (HTTP
requests) and calculation of checksums consume too much time. I had to
take this back. Then I started to investigate about checksum algorithms
in general and its usage in Maven Central. Maven Central first: Brian
Fox said that this is in investigation, but as you know yourself the
entire ecosystem needs to prepare itself for this. We are talking about
millions of consumers. A hard nut to crack.
As for the checksum algorithms: SHA-x, compared to other cryptographic
algorithms, performs horribly, SHA-2 worse than SHA-1. If you are
downloading thousands of artifacts this does matter, actually. Even
Blake2/Blake3 do a much better job than SHA-x. Another question: Why do
we need a cryptographic hash at all? We don't for bitrot. It is a waste
of cycles. Looking at MurmurHash or xxHash makes SHA-2 just look ridiculous.
My personal opinion: Unless Oracle/OpenJDK adds non-crypto hash algos to
MessageDigest SPI the overhead of SHA-2 might neutralize its benefit.
Also keep in mind when this stuff has been designed, when HTTP was used
throughout. TLS hash hashing builtin. I think the previous bitrot case
should be much much rarer.
Michael
PS: I am not a security expect, just sharing my findings in this context.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
