There is no Security risk with weaker checksums since the checksums are not used for security. An attacker who messes with your binaries can also mess with the checksum files. Only the signatures are relevant here (and they depend on the PGP settings if they use strong hashes).
And even the broken/short/fast md5 would be strong enough to detect bit errors, especially considering TLS is now mandatory. Having said that, I guess the policy should come from maven central what’s required for new uploads. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: Mickael Istria <[email protected]> Gesendet: Wednesday, October 13, 2021 4:19:09 PM An: Maven Developers List <[email protected]> Betreff: Re: MD5, SHA1, but nothing (still) safe? On Wed, Oct 13, 2021 at 2:10 PM Michael Osipov <[email protected]> wrote: > Hi Mickael, > Hi Michael, > > 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. > Sorry for being confusing. I really mean checksums and verifying data integrity in the transfer (bitrot). 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. I couldn't find this discussion; I probably miss something. Is it buried in another thread? Ideally, do you think you could share a link? I'm surprised about those extra HTTP requests and calculation of checksums being a too big issue compared to the security risk. > 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. > OK thanks for the info. 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. Sure, SHA-256 is more expansive, but now SHA-1 has been broken for some time already and isn't worth much in term of security. Keeping reliance on MD5 and SHA1 seems quite insecure. > Why do > we need a cryptographic hash at all? We don't for bitrot. It is a waste > of cycles. What do you use for bitrot then? Unsecure algorithms? p2 has mirror capabilities, one does fetch the p2 metadata from a trusted location (eg https://download.eclipse.org) and this metadata contains the artifacts with checksums, size and other info. This metadata can also include a lit of mirrors to use in place of the main server; those mirrors can use unsafe protocols or even be malicious themselves. Having checksums in a trusted locations does prevent mirrors from injecting malicious artifacts; and also allows to keep using "unsafe" protocols in a safer way. > 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. As mentioned above, things like mirroring make it still very relevant.
