Build.gradle double signing (signing plugin)

deanhiller · January 19, 2020, 6:59pm

I have the following build.gradle file with a signing plugin

deanhiller/webpieces/blob/master/build.gradle

buildscript {
    repositories {
        jcenter()
        mavenCentral()

        //Comment out to suck in dependencies from local repo
        //sometimes you want to build the gradle plugin and then feed into your current project
        //and this allows you to build the local one then use it
        //maven {
        //    name = 'myTemp'
        //    url = "file:/tmp/myRepo/"
        //}
    }

    dependencies {
        classpath 'nl.javadude.gradle.plugins:license-gradle-plugin:0.11.0'
        classpath 'gradle.plugin.co.riiid:gradle-github-plugin:0.4.2'
        //we created a pull request on this but until then, use our customer forked one
        classpath fileTree(dir: 'gradle/deanslib', includes: ['gradle-nexus-staging-plugin-0.5.4-SNAPSHOT.jar'])
        //classpath "io.codearte.gradle.nexus:gradle-nexus-staging-plugin:0.5.3"

This file has been truncated. show original

BUT the resulting files should be
core-asyncserver-2.0-developer.jar
core-asyncserver-2.0-developer.jar.asc
core-asyncserver-2.0-developer.jar.md5
core-asyncserver-2.0-developer.jar.sha1

BUT instead there are 2 more files as well as it seems the *.asc files are being signed too after they are generated so I also end up with these 2 files
core-asyncserver-2.0-developer.jar.asc.md5
core-asyncserver-2.0-developer.jar.asc.sha1

This project only compiles on jdk8 right now, and I run ./gradlew clean release -x javadoc (also, on a side note, I ended up with core-asyncserver-2.0-developer-javadoc.jar which is funny since I ran with -x javadoc).

The gradle version is defined in that project with the gradle wrapper. Anyone know why it’s signing the asc files?

jjustinic · January 20, 2020, 4:41am

It’s not. The result of signing core-asyncserver-2.0-developer.jar is the core-asyncserver-2.0-developer.jar.asc file. The .asc file is the signature.

Both of these files are uploaded to the artifact repository. Any file that is going to be uploaded to artifact repository has checksums generated (.md5 / .sha1). This guarantees the contents of the file weren’t corrupted in transmission. The checksums are generated for the files regardless of whether you sign the files you’re transmitting, and adding a signature doesn’t circumvent or add special exceptions to the normal checksum process.

deanhiller · January 20, 2020, 2:29pm

I am not sure I am reading you correctly…

PUT another way, I expected a file list like jackson has
https://repo1.maven.org/maven2/com/fasterxml/jackson/core/jackson-core/2.10.1/

INSTEAD my file list is a lot longer because of the extra *.asc.md5 and *.asc.sha1 files
https://repo1.maven.org/maven2/org/webpieces/core-asyncserver/2.0.5/

BUT perhaps you are saying since core-asyncserver-2.0-developer.jar.asc is going to uploaded, then the *.asc file ALSO generates checksums core-asyncserver-2.0-developer.jar.asc.md5 and core-asyncserver-2.0-developer.jar.asc.sha1. (I expected the *.asc file, but was perplexed around the *.asc.md5 and *.asc.sha1 file since no other maven deploys I see in maven central have *.asc.md5 and *.asc.sha1). Of course, jackson and most releases are not doing this?

PLEASE NOTE: in your text, you are referring to the jar having checksums, but in this case, I am also seeing checksums on the *.asc file.

thanks,
Dean

deanhiller · January 27, 2020, 2:57pm

anyone? (must be at least 20 characters so here are my 20)

jjustinic · January 28, 2020, 2:54am

The main point of my post was to clarify what you actually were trying to ask. Both your post and the comments in the code suggested a misunderstanding of the concepts. Specifically,

BUT even if we remove the signing section, we still end up generating *.md5 and *.sha1 so apparently things are still being signed.

The *.asc file is the signature, so when you remove the signing section, the *.asc file is what should be removed. The presence of *.md5 and *.sha1 is a checksum, not a signature.

With that out of the way, I think the question you actually ended up wanting to ask was, “Why are checksums being generated for the signature file?”, but I wasn’t completely sure from your first post.

deanhiller · January 28, 2020, 3:57am

yes @jjustinic, you hit the head on the nail. I guess on my reply I should have mentioned that! To be clear, after your first answer, I went and read and went ‘ohhhh, oops, those were checksums’. Any ideas why we are doing checksums on the *.asc file? That seems a bit weird from other maven repos I checked out.

thanks,
Dean