[
https://issues.apache.org/jira/browse/SLING-7534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17208168#comment-17208168
]
Michael Osipov commented on SLING-7534:
---------------------------------------
Here is a lot of fuzz and non-sense going on. I think I need to break a stab
here:
First of all, a Maven 2 repo always includes MD5 and SHA-1 checksums. You
cannot remove it. This is enforced and mandated by Nexus. I have talked with
Brian Fox about this (see dev@maven some time ago), this is also not so easy to
solve for Maven Central. Sonatype is analyzing the issue, but SHA-256 and
SHA-512 are not required in Central. SHA-2 and SHA-3 perform really really slow
compared to Blake. I am quite certain that this will lead to issues in the
future and must be considered to allow Blake3 hashes as well for maximum perf.
Now the important thing: You are completely mixing Apache release process
requirements and Maven transport of artifacts:
* Release: you must upload source-release.zip with SHA-2 family hash for dist.
Period. How you generate it is completely your problem.
* maven-install-plugin: It's sole task to copy all artifacts in the reactor to
the local Maven repo. That's it.
* maven-deploy-plugin: It's sole task is to copy all artifacts in the reactor
which are locally installed to a remote location by using Maven Artifact
Transfer which uses Maven Resolver. No checksums are generated by
maven-deploy-plugin or Maven Artifact Transfer.
Excourse: What are hashes used for with Maven? It is used to detect bitrot
during transfer, i.e., has the file being corrupt by some transport mechanism.
By no means to verify its authenticity (hello signatures). Maven Resolver
generates those checksums and hands them off to a transport implementation to
avoid bitrot. No more, no less. All checksums are opaque and an implementation
detail of Maven Resolver, they are not and must not be exposed to any upper
level. Maven does not care where an artifact came from, all it cares its
integerity has been verified by some means and it is available in the local
repo. When you configure Resolver to generate SHA-256 for the transport it will
do on all requests files (artifacts), if not file an issue. You will *not* have
access to those checksums.
If you need checksums for your disposal at release time go exactly here:
https://github.com/apache/maven/blob/master/apache-maven/pom.xml#L310-L336
> Release policy - stop providing MD5 and start providing SHA-512 checksums
> -------------------------------------------------------------------------
>
> Key: SLING-7534
> URL: https://issues.apache.org/jira/browse/SLING-7534
> Project: Sling
> Issue Type: Task
> Components: Tooling
> Reporter: Robert Munteanu
> Assignee: Konrad Windszus
> Priority: Major
> Fix For: Parent 40
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> See http://www.apache.org/dev/release-distribution#sigs-and-sums , we SHOULD
> no longer provide MD5 checksums for new releases.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
