Publish to OSSRH

[gliptak]

Signed-off-by: Gábor Lipták gliptak@gmail.com

@arnaudroques I don't have a way to test

[arnaudroques]

@arnaudroques I don't have a way to test

Sure, I understand that the only way to test is to create a new release.
So, if that's ok for you, I'm going to tag a new V1.2022.9 even if there is nothing really new in the code.
We will see the result :-)

Sounds good?

[gliptak]

sounds good @arnaudroques

[arnaudroques]

sounds good @arnaudroques

Ok, the CI has run :-)
However, it looks like nothing has been pushed to OSSRH. Any idea?
Thanks!

[arnaudroques]

However, it looks like nothing has been pushed to OSSRH. Any idea?

My mistake: it seems to have pushed something :-)

[arnaudroques]

However, I cannot release this version on https://oss.sonatype.org/
There is some missing signature (see attached image):

Any idea? Thanks!

[gliptak]

@arnaudroques looking

signing seem to be in path

https://github.com/plantuml/plantuml/blob/master/.github/workflows/ci.yml#L141
https://github.com/plantuml/plantuml/blob/master/build.gradle.kts#L167

[gliptak]

https://sourceforge.net/p/plantuml/code/HEAD/tree/trunk/pom.xml#313 has a similar sign section

https://repo1.maven.org/maven2/net/sourceforge/plantuml/plantuml/1.2022.8/ has more files than https://github.com/plantuml/plantuml/releases/tag/v1.2022.9

I also downloaded https://repo1.maven.org/maven2/net/sourceforge/plantuml/plantuml/1.2022.8/plantuml-1.2022.8.jar and it is unsigned ...

jarsigner -verify plantuml-1.2022.8.jar
jar is unsigned.

#1138

maybe release v1.2022.9.1 and review logs?

[arnaudroques]

maybe release v1.2022.9.1 and review logs?

Let's go for v1.2022.10. We have some space left up to v1.2022.99 :-)

About the log in https://github.com/plantuml/plantuml/actions/runs/3141306358/jobs/5103659727 :

Skipping task ':jar' as it is up-to-date.

Does it mean than signing is not done ? Also, the key I was using with maven (which is stored locally on some local server) is different from the key used by GitHub. Not sure if it's an issue or not.

I've go two more interesting screenshots:

It's probably unrelated but we've got: Project name missing and Project description missing. Maybe we can take this opportunity to fix those. (unfortunately, I have no idea about where to fix it)

Thanks for your help!

[arnaudroques]

On second though, it looks like .asc signature files were not pushed to OSSRH (plantuml-1.2022.10.jar.asc does not exists for plantuml-1.2022.10.jar). Even if is has been generated on github ( https://github.com/plantuml/plantuml/releases/download/v1.2022.10/plantuml-1.2022.10.jar.asc ).

Are there some logs about what is actually pushed to OSSRH? (to check whether those .asc files are present or not)

jarsigner -verify plantuml-1.2022.8.jar
jar is unsigned.

I'm definitively not an expert here but I think it may be a different story.
The internal signature of jar files based on filenames with .sf extension stored in JAR's META-INF directory is not related with the .asc files github and OSSRH are expecting. So yes, I think that our .jar files are not signed. (Note that signing internally those .jar file is something we could add latter when publishing to OSSRH will be fixed, since some users have asked for that)

[gliptak]

Skipping task ':jar' as it is up-to-date. this refers to jar task not the signing task

if there is a chance that the Github key is no longer valid, consider updating with the "local" signing key

at this point, I don't know what other updates are required to correct the signing process

#1143

[arnaudroques]

at this point, I don't know what other updates are required to correct the signing process

Ok, thanks!
@soloturn since you have help in the past about maven, if you have some time, maybe you can have an look on this.

Both of you have write access now, so you may create some branch and debug the CI there if you wish, without me being on the bottleneck.

I think we are not far from success :-)

[gliptak]

let's plan to review #1143 results during next (proper) release

[arnaudroques]

let's plan to review #1143 results during next (proper) release

Ok, but before doing that, can we set up some verbose mode about the signing process to have a look on the log?

I guess that something must be missing because in the signing part of gradle.
There are some reference about password and passphrase in the CI and in build.gradle.kts.
Is there a way to trace whether signing.gnupg.keyName, signing.gnupg.passphrase, signingKey and signingPassword are correctly set?

[soloturn]

@arnaudroques @gliptak, i tried to understand, but could not yet. what is the background of this change? and - thanks for the invite, but i was too slow to see it, it expired after 7 days blush

[gliptak]

@soloturn we were updating Gradle build to enable publishing to ossrh
At this point, signing doesn't happen right
This and linked PRs captured change evolution

[soloturn]

@gliptak, @arnaudroques, how do you check if the signature is good? after downloading the newest released files from here:
https://github.com/plantuml/plantuml/releases/tag/v1.2022.10

the following happens:

$ gpg --keyserver-options auto-key-retrieve --verify plantuml-1.2022.10-javadoc.jar.asc 
gpg: assuming signed data in 'plantuml-1.2022.10-javadoc.jar'
gpg: Signature made Wed 28 Sep 2022 08:38:32 AM CEST
gpg:                using RSA key 019586D44BD80213
gpg: Can't check signature: No public key

when searching the key or email nothing is found:
https://keys.openpgp.org/search?q=019586D44BD80213
https://keys.openpgp.org/search?q=plantuml%40gmail.com

if one takes anything else, arbitrary, e.g. https://repo1.maven.org/maven2/io/github/ncasaux/camel-plantuml/1.4.0/ :

$ gpg --keyserver-options auto-key-retrieve --verify /tmp/camel-plantuml-1.4.0.pom.asc 
gpg: assuming signed data in '/tmp/camel-plantuml-1.4.0.pom'
gpg: Signature made Thu 01 Sep 2022 10:55:58 PM CEST
gpg:                using RSA key D35D6E8E97E9E45D020A4144A5A5524DEABE9E8C
gpg: key A5A5524DEABE9E8C: public key "Nicolas Casaux <nicolas.casaux@outlook.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1
gpg: Good signature from "Nicolas Casaux <nicolas.casaux@outlook.com>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: D35D 6E8E 97E9 E45D 020A  4144 A5A5 524D EABE 9E8C

@arnaudroques you mind uploading the public key? i did not find it, otherwise i would have tried uploading it and you might have gotten an email for verification, if i am not wrong.

[arnaudroques]

@arnaudroques you mind uploading the public key? i did not find it, otherwise i would have tried uploading it and you might have gotten an email for verification, if i am not wrong.

Sure, the key is available here.

To be honest, I'm completely lost on those subjects :-)
I think this key is used when I run maven locally, because:

gpg --list-packets pgp_plantuml_jar_signing_key.txt
# off=0 ctb=99 tag=6 hlen=3 plen=525
:public key packet:
        version 4, algo 1, created 1639074328, expires 0
        pkey[0]: [4096 bits]
        pkey[1]: [17 bits]
        keyid: 019586D44BD80213
# off=528 ctb=b4 tag=13 hlen=2 plen=45
:user ID packet: "PlantUML JAR Signing Key <plantuml@gmail.com>"
# off=575 ctb=89 tag=2 hlen=3 plen=590
:signature packet: algo 1, keyid 019586D44BD80213
        version 4, created 1639074328, md5len 0, sigclass 0x13
        digest algo 8, begin of digest 77 63
        hashed subpkt 33 len 21 (issuer fpr v4 C08C18EE1706DB378BD993C8019586D44BD80213)
        hashed subpkt 2 len 4 (sig created 2021-12-09)
        hashed subpkt 27 len 1 (key flags: 03)
        hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 2)
        hashed subpkt 21 len 5 (pref-hash-algos: 10 9 8 11 2)
        hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
        hashed subpkt 30 len 1 (features: 01)
        hashed subpkt 23 len 1 (keyserver preferences: 80)
        subpkt 16 len 8 (issuer key ID 019586D44BD80213)
        data: [4094 bits]
# off=1168 ctb=b9 tag=14 hlen=3 plen=525
:public sub key packet:
        version 4, algo 1, created 1639074328, expires 0
        pkey[0]: [4096 bits]
        pkey[1]: [17 bits]
        keyid: 449BF54F8FDED249
# off=1696 ctb=89 tag=2 hlen=3 plen=566
:signature packet: algo 1, keyid 019586D44BD80213
        version 4, created 1639074328, md5len 0, sigclass 0x18
        digest algo 8, begin of digest e9 ec
        hashed subpkt 33 len 21 (issuer fpr v4 C08C18EE1706DB378BD993C8019586D44BD80213)
        hashed subpkt 2 len 4 (sig created 2021-12-09)
        hashed subpkt 27 len 1 (key flags: 0C)
        subpkt 16 len 8 (issuer key ID 019586D44BD80213)
        data: [4095 bits]

So we retrieve the ID using RSA key 019586D44BD80213.

Now I think there is a passphrase on this key which is stored in the secret ARTIFACT_SIGNING_PASSPHRASE and that the corresponding secret key is ARTIFACT_SIGNING_KEY, but I'm only 99% sure about it :-)

[arnaudroques]

@soloturn Thanks for mentioning https://keys.openpgp.org/search?q=019586D44BD80213

The public key has just been published.
It would likely help :-)

[arnaudroques]

Publishing the key did not really help.
The CI has run for a new tag and there are still the same errors in https://oss.sonatype.org/

However, here is a clue: it seems that some .asc files are missing. Those are likely the signature which is missing. It looks like there are not generated by the CI on github. Any idea?
(Edited : here an example of asc file)

Projet name and project description are also still missing in the generated .pom file.

Thanks!

[arnaudroques]

To get things even stranger, the .asc files are generated on github side (see for example)

However, they don't seem to be pushed/published to https://oss.sonatype.org/

Does the order matter in build.gradle.kts ?
Do we need to declare publishing after signing ?

We should probably add debug logs for the "Upload artifacts" but I'm not sure about how set this...

[gliptak]

GHA sequences those calls

https://github.com/plantuml/plantuml/actions/runs/3316317804/jobs/5478022205

Signing happens before the upload/release/publish steps (although publish does target to rebuild https://github.com/plantuml/plantuml/actions/runs/3316317804/jobs/5478022205#step:8:55)

[arnaudroques]

@gliptak Thanks for your help and explanation!

Would it be possible to have more trace/log on what is happing in publishMavenPublicationToOSSRHRepository or publish ?
Maybe by adding some flags here or here ?

Because I cannot understand why the signature .asc files are not published to https://oss.sonatype.org/

[soloturn]

does for you the check of gh pblished files work? for me still not. maxbe key is wrong, signing is wrong or publishing pubkey is wrong?

> gpg --verify plantuml-1.2022.12.jar.asc 
gpg: assuming signed data in 'plantuml-1.2022.12.jar'
gpg: Signature made Mo 24 Okt 2022 23:40:17 CEST
gpg:                using RSA key 019586D44BD80213
gpg: Can't check signature: No public key

my feeling is we should get this running local firszt.

[pzygielo]

works for me:

$ gpg --verify plantuml-1.2022.12.jar.asc 
gpg: assuming signed data in 'plantuml-1.2022.12.jar'
gpg: Signature made Mon 24 Oct 2022 23:40:17 CEST
gpg:                using RSA key 019586D44BD80213
gpg: Good signature from "PlantUML JAR Signing Key <plantuml@gmail.com>" [full]

[soloturn]

interesting. need to look in more detail local then.

for upload i saw:
https://discuss.gradle.org/t/uploadartifacts-skips-asc-files-during-upload-of-multiple-artifacts-in-multi-module-project/2145/7

[arnaudroques]

https://discuss.gradle.org/t/uploadartifacts-skips-asc-files-during-upload-of-multiple-artifacts-in-multi-module-project/2145/7

Yes, that sounds like the same issue we have :-)

If you have the time to propose a MR to test the upload of asc files, we will be glad to merge it.
We could begin with only a single asc file if you wish.

Thanks!

[evantill]

It's probably unrelated but we've got: Project name missing and Project description missing. Maybe we can take this opportunity to fix those. (unfortunately, I have no idea about where to fix it)

Just add the name and the description in the build.gradle.kts file :

[...]
publishing {
[...]
		pom {
                name.set("HERE THE PROJECT NAME")
                description.set("HERE A concise description of THE PROJECT")
[...]

[evantill]

I'm trying to reproduce the problem locally.

Here is what I have already tried :

• running a nexus in a doker container
• executing the following commands in this order (to simulate the git workflow):

gradle -q compileJava --no-daemon
gradle test --no-daemon -i
gradle -q clean build \
            pdfJar \
            generateMetadataFileForMavenPublication generatePomFileForMavenPublication \
            -x test
gradle -i signMavenPublication signPdfJar
gradle publish

But I have not reproduced the problem :

[evantill]

Is it possible to trigger a new release to check the logs of the git workflow ?

The next test is to try to simulate the workflow using https://github.com/nektos/act

[evantill]

I think I have spotted a bug in the workflow 👯‍♂️.
I have created a nexus instance at https://nexus.evaxion.fr to try to reproduce the problem.
I will test it and create a PR.

[evantill]

Not sure why, but the good news is that I can reproduce it :

• uploaded artifacts from github workflow are not signed.
• uploaded artifacts running gradle command from my laptop are signed.

I think I have the reason :
The signing tasks are defined only if the signing properties are configured.
But when we gradle run the publish tasks, the properties are not configured anymore, so the tasks are not definined any more. The task dependencies that not see the signing tasks.

I will test it

[arnaudroques]

Not sure why, but the good news is that I can reproduce it :

• uploaded artifacts from github workflow are not signed.
• uploaded artifacts running gradle command from my laptop are signed.

That's great!
Because if it can be reproduced, it can be fixed.

Good luck ;-)

[evantill]

should be fixed by PR #1314

Tested on my repository