Provide option for configuring `publishAllChecksums` when using `com.gradleup.nmcp` plugin

[marcphilipp]

What feature do you want to see added?

When using the com.gradleup.nmcp plugin, there's currently no way to configure publishAllChecksums to be true because it's hard-coded as false:

nmcp/nmcp/src/main/kotlin/nmcp/internal/DefaultNmcpExtension.kt

Line 81 in 92e0f77

publishAllChecksums = project.provider { false }

Could you please add an option to NmcpExtension for configuring it?

Upstream changes

Recent introduction of checksum filtering

Are you interested in contributing this feature?

Yes, I could do that if you agree this is the right solution.

[martinbonnin]

Thanks for opening this and apologies for breaking your workflow as I tend to focus on the aggregation case.

2 questions:

• why do you need the checksums? I'm genuinely curious since Gradle almost never uses it (I think there's an optimization case but it sounds quite niche). I was hoping long term we could deprecate publishAllChecksums
• If you really need them, could you use both com.gradleup.nmcp and com.gradleup.nmcp.aggregation? The option is not hardcoded for the aggregation.

plugins {
  id("com.gradleup.nmcp") // for exposing all the publications
  id("com.gradleup.nmcp.aggregation") // for configuring the aggregation
}

nmcpAggregation {
  centralPortal {
    username.set("")
    password.get("")
    publishAllChecksums.set(true)
  }
}

dependencies {
  nmcpAggregation(project)
}

[marcphilipp]

Thanks for the quick reply! 👍

why do you need the checksums?

Since sha1 and md5 are weak/insecure, we'd like to keep publishing sha256/sha512 checksums. While one should rather verify the signatures to ensure files have not been tampered with, some folks might use the checksums for that. In addition, JUnit has users who don't use Gradle/Maven but download and verify jars directly. They also could be relying on those to be present.

I think filtering out checksums for signature files makes sense, though. Gradle also seems to be moving in that direction (see gradle/gradle#20232 (comment)). For the main JUnit repo, I've now enabled publishAllChecksums and filtered out those myself (see junit-team/junit-framework@673d68f). Would be great if that were an option of the nmcp plugins directly.

If you really need them, could you use both com.gradleup.nmcp and com.gradleup.nmcp.aggregation? The option is not hardcoded for the aggregation.

I suppose then I might as well switch to the settings plugin, right? In any case, I'd then have to use the publishAggregationToCentralPortal task instead of publishAllPublicationsToCentralPortal, correct? I was trying to keep things simple for single-project repos such as https://github.com/junit-team/testng-engine.

[martinbonnin]

While one should rather verify the signatures to ensure files have not been tampered with, some folks might use the checksums for that. In addition, JUnit has users who don't use Gradle/Maven but download and verify jars directly. They also could be relying on those to be present.

Is there evidence of people doing this? Since the files are next to each other, I'm not sure this gives any amount of security? If someone can tamper with the .jar files, surely, they can also tamper with its checksum?

For the main JUnit repo, I've now enabled publishAllChecksums and filtered out those myself (see junit-team/junit-framework@673d68f). Would be great if that were an option of the nmcp plugins directly.

Let's see where the community lands on this. My hunch is that sending and storing checksums in Central puts additional stress on the shared infrastructure for very little (if any) benefit and we should all be better not publishing those.

I also have an ongoing discussion with @brianf to remove the requirement to publish checksums altogether (including md5 and sha1). Maybe the conclusion is that we actually need those but so far I don't think anyone has a compelling use case.

I suppose then I might as well switch to the settings plugin, right? In any case, I'd then have to use the publishAggregationToCentralPortal task instead of publishAllPublicationsToCentralPortal, correct? I was trying to keep things simple for single-project repos such as https://github.com/junit-team/testng-engine.

Right 👍 . The settings plugin is the easiest entry point for most users. It wasn't a thing initially but I'd like to steer usage that direction.