Not publishing checksums for `maven-metadata.xml` causes alarming warnings when consuming snapshots from Maven

[marcphilipp]

Expected and Results

Currently, when consuming snapshots of JUnit artifacts from a Maven build, the following warnings are printed to the build output:

Downloading from sonatype-snapshots: https://central.sonatype.com/repository/maven-snapshots/org/junit/platform/junit-platform-engine/6.2.0-SNAPSHOT/maven-metadata.xml
[WARNING] Checksum validation failed, expected 'c58c99c32d38fb681e9eb49a7a7e94b8732793be' (REMOTE_EXTERNAL) but is actually 'a4978025dd471200d4c7dff8112fa4e9881dd262' from sonatype-snapshots for https://central.sonatype.com/repository/maven-snapshots/org/junit/platform/junit-platform-engine/6.2.0-SNAPSHOT/maven-metadata.xml
[WARNING] Could not validate integrity of download from https://central.sonatype.com/repository/maven-snapshots/org/junit/platform/junit-platform-engine/6.2.0-SNAPSHOT/maven-metadata.xml
org.eclipse.aether.transfer.ChecksumFailureException: Checksum validation failed, expected 'c58c99c32d38fb681e9eb49a7a7e94b8732793be' (REMOTE_EXTERNAL) but is actually 'a4978025dd471200d4c7dff8112fa4e9881dd262'
    at org.eclipse.aether.connector.basic.ChecksumValidator.validateExternalChecksums (ChecksumValidator.java:179)
    at org.eclipse.aether.connector.basic.ChecksumValidator.validate (ChecksumValidator.java:109)
    at org.eclipse.aether.connector.basic.BasicRepositoryConnector$GetTaskRunner.runTask (BasicRepositoryConnector.java:486)
    at org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run (BasicRepositoryConnector.java:416)
    at org.eclipse.aether.connector.basic.BasicRepositoryConnector.get (BasicRepositoryConnector.java:215)
    at org.eclipse.aether.internal.impl.DefaultMetadataResolver$ResolveTask.run (DefaultMetadataResolver.java:556)
    at org.eclipse.aether.util.concurrency.RunnableErrorForwarder.lambda$wrap$0 (RunnableErrorForwarder.java:66)
    at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolve (DefaultMetadataResolver.java:352)
    at org.eclipse.aether.internal.impl.DefaultMetadataResolver.resolveMetadata (DefaultMetadataResolver.java:180)
    at org.apache.maven.repository.internal.DefaultVersionResolver.resolveVersion (DefaultVersionResolver.java:199)
    at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom (DefaultArtifactDescriptorReader.java:212)
    at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor (DefaultArtifactDescriptorReader.java:183)
    at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.resolveCachedArtifactDescriptor (DfDependencyCollector.java:382)
    at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.getArtifactDescriptorResult (DfDependencyCollector.java:368)
    at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.processDependency (DfDependencyCollector.java:218)
    at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.processDependency (DfDependencyCollector.java:156)
    at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.process (DfDependencyCollector.java:138)
    at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.doRecurse (DfDependencyCollector.java:343)
    at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.processDependency (DfDependencyCollector.java:277)
    at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.processDependency (DfDependencyCollector.java:156)
    at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.process (DfDependencyCollector.java:138)
    at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.doRecurse (DfDependencyCollector.java:343)
    at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.processDependency (DfDependencyCollector.java:277)
    at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.processDependency (DfDependencyCollector.java:156)
    at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.process (DfDependencyCollector.java:138)
    at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.doCollectDependencies (DfDependencyCollector.java:108)
    at org.eclipse.aether.internal.impl.collect.DependencyCollectorDelegate.collectDependencies (DependencyCollectorDelegate.java:222)
    at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies (DefaultDependencyCollector.java:87)
    at org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies (DefaultRepositorySystem.java:306)
    at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve (DefaultProjectDependenciesResolver.java:151)
    at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies (LifecycleDependencyResolver.java:227)
    at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies (LifecycleDependencyResolver.java:136)
    at org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved (MojoExecutor.java:355)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:314)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:212)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:174)
    at org.apache.maven.lifecycle.internal.MojoExecutor.access$000 (MojoExecutor.java:75)
    at org.apache.maven.lifecycle.internal.MojoExecutor$1.run (MojoExecutor.java:162)
    at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute (DefaultMojosExecutionStrategy.java:39)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:159)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:105)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:73)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:53)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:118)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:919)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:285)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:207)
    at jdk.internal.reflect.DirectMethodHandleAccessor.invoke (DirectMethodHandleAccessor.java:104)
    at java.lang.reflect.Method.invoke (Method.java:565)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:255)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:201)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:362)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:314)

This is due to having uploaded checksums for maven-metadata.xml with nmcp plugin 1.5.0 and now no longer uploading them since having upgraded to 1.6.0.

Not publishing checksums is probably fine for new artifacts/versions, but for this use case, I'd like to be able to enable publishing checksums again.

Related environment and versions

Gradle 9.6.1
Plugin version 1.6.0

Reproduction steps

Add the https://central.sonatype.com/repository/maven-snapshots/ repo and 6.2.0-SNAPSHOT of JUnit artifacts.

Anything else?

Root cause:

• Do not publish checksums for maven-metadata #258

[martinbonnin]

That's super interesting, thanks for reporting this.

This is due to having uploaded checksums for maven-metadata.xml with nmcp plugin 1.5.0 and now no longer uploading them since having upgraded to 1.6.0.
Not publishing checksums is probably fine for new artifacts/versions, but for this use case, I'd like to be able to enable publishing checksums again.

Just making sure I understand, we have different types of files:

• signatures (.asc) => no checksum should be sent
• artifacts (.jar) => md5 and sha1 are required by Central and are sent. Following the comment from @leonard84, I'm planning to also send .sha512 in the next version. There is also a separate feature request to Central that they compute the checksums on their side so that it doesn't require alignment of all the publishers.
• maven-metadata.xml (for snapshots) => There is no Central requirement there but it looks like maven is doing a check. I'm OK do add back a checksum but would like to avoid overcomitting.

Questions:

• Is it enough to send .sha512 for maven-metadata.xml?
• Should we file a feature request for maven to not download the checksum if it's in the same repository than the one the jar was downloaded from. That seems superfluous?

[marcphilipp]

Is it enough to send .sha512 for maven-metadata.xml?

Maven seems to validate sha1:

$ curl https://central.sonatype.com/repository/maven-snapshots/org/junit/platform/junit-platform-engine/6.2.0-SNAPSHOT/maven-metadata.xml.sha1
c58c99c32d38fb681e9eb49a7a7e94b8732793be%

Should we file a feature request for maven to not download the checksum if it's in the same repository than the one the jar was downloaded from. That seems superfluous?

I think Maven downloads checksums for every file it downloads from a repo to validate its integrity. Therefore, I don't see how it's related to the jar/pom/etc. it will download after looking at the metadata.

[martinbonnin]

Maven seems to validate sha1

Just bumped into that interesting page: https://maven.apache.org/resolver/about-checksums.html

Maven 3.8.1+ should support .sha512 but then this part feels weird:

So to say, secure one-way hashes provided by Java Cryptography Architecture were (mis)used to implement checksums 
for transport integrity validation. There is no misunderstanding here, secure hashes MAY be used as checksums, as 
there is quite some overlap between checksums and hashes in general. But this simplicity comes at a price: 
cryptographically safe algorithms require way more CPU cycles to calculate checksum, while all their purpose is 
just integrity validation, nothing more. There is no security, trust or whatever else implied or expected from them.

If you are interested in trust in your artifacts, it is signatures (for example [GPG Signatures](https://maven.apache.org/plugins/maven-gpg-plugin/)) that you should look for.

Hence, the usual argument that “XXX algorithm is unsafe, deprecated, not secure anymore” does not stand in use 
case of Maven Resolver: there is nothing secure being involved with checksums. Moreover, this is true not only for 
SHA-1 algorithm, but even for its “elder brother” MD5. Both algorithms are still widely used today as “transport integrity 
validation” or “error detection” (aka “bit-rot detection”).

I think Maven downloads checksums for every file it downloads from a repo to validate its integrity.

This is the part I didn't get before. Under a "security" point of view, this is not required. If you trust the repo then no need to revalidate. But it looks like they trust the repo but not the "transport". Which sounds surprising...

This is all a huge mess. But at least I see it clearer now. I'll make a new version that uploads:

• .md5, .sha1 for Maven "transport validation" (even if I'm still not convinved this is required in 2026)
• .sha512 for Gradle "security validation" (even if I'd like those to be computed on the Maven Central side)

Thanks for all the feedback and your patience as we navigated all of this!

[martinbonnin]

Should be all good with 1.6.1. Let me know how that goes

[marcphilipp]

The warnings are gone after publishing snapshots with 1.6.1. Thanks for the quick turnaround!

[CLOVIS-AI]

But it looks like they trust the repo but not the "transport". Which sounds surprising...

For HTTP (not S) users, that makes sense.

[martinbonnin]

For HTTP (not S) users, that makes sense.

Sure. But the warning especially mentions "https" here. I'm curious how many people are still using HTTP.