Am 2021-10-13 um 16:19 schrieb Mickael Istria:
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.
See the vote (discussion) on Maven Resolver 1.6.0.
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.
For security, yes. But as said, we don't need security here. Just integrity.
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.
Well, checksums don't create trust. If you are talking about trust you
are back to signatures. Providing checksums upfront just tell you that
there is no bitrot in-between which you want to avoid. You still cannot
verify who provided this artifact with this.
We had a very extensive talk about this in our monthly Apéro and we only
agreed that it is very hard to make signature checking right for the
masses and it would only apply to Maven Central. What happens with in
house repos: no idea.
You basically want:
* https://issues.apache.org/jira/browse/MRESOLVER-218
* https://issues.apache.org/jira/browse/MNG-6026
* https://issues.apache.org/jira/browse/MNG-5814
M
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
