[Build] Apply best practices to Maven artifact singing and use BC-signer #2731
Conversation
| @@ -89,15 +89,11 @@ pipeline { | |||
| // The location of the temporarily file that contains the secret file content | |||
| // (see https://www.jenkins.io/doc/book/pipeline/syntax/#supported-credentials-type): | |||
| KEYRING = credentials("secret-subkeys-${PROJECT == 'platform' ? 'releng': PROJECT}.asc") | |||
| MAVEN_GPG_PASSPHRASE = credentials("secret-subkeys-${PROJECT == 'platform' ? 'releng': PROJECT}.acs-passphrase") | |||
There was a problem hiding this comment.
There is currently only the passphrase for the GPG-key for releng/platform stored as secret-subkeys-releng.acs-passphrase secret text in the Releng-JIPP:
https://ci.eclipse.org/releng/credentials/store/system/domain/_/credential/secret-subkeys-releng.acs-passphrase/
@fredg02 or @heurtematte could you please add the passphrases for the PDE and JDT key correspondingly?
I searched for a corresponding configuraiton in https://github.com/eclipse-cbi/jiro/tree/master/instances/eclipse.platform.releng, but failed to find anything in this regard.
The corresponding keys are already available as:
secret-subkeys-releng.ascsecret-subkeys-pde.ascsecret-subkeys-jdt.asc
Can you also tell if the keys have the TSK format (saved ASCII armored?)?:
https://openpgp.dev/book/private_keys.html#transferable-secret-key-format
Respectively can these keys be used with the maven-gpg-plugin without being imported by gpg locally?
https://maven.apache.org/plugins/maven-gpg-plugin/sign-and-deploy-file-mojo.html#keyFilePath
There was a problem hiding this comment.
I have just added passphrase: secret-subkeys-jdt.asc-passphrase and secret-subkeys-pde.asc-passphrase
Can you also tell if the keys have the TSK format (saved ASCII armored?)?:
Keys are not in TSK format.
Respectively can these keys be used with the maven-gpg-plugin without being imported by gpg locally?
As mentioned in documentation, gpg seems to be the more secure way or by using env variable.
There was a problem hiding this comment.
I have just added passphrase:
secret-subkeys-jdt.asc-passphraseandsecret-subkeys-pde.asc-passphrase
Thank you. While testing the new passphrases I noticed that for the existing passphrase variable the name (probably) has a typo: secret-subkeys-releng.acs-passphrase should probably be secret-subkeys-releng.asc-passphrase so asc instead of acs. Could you please add a copy with a fixed name. I can then also adapt the other references to that secret.
Respectively can these keys be used with the maven-gpg-plugin without being imported by gpg locally?
As mentioned in documentation, gpg seems to be the more secure way or by using env variable.
Eventually I would like to get rid of the explicit gpg --import at the beginning of the script below. When using the Tycho-GPG-plugin to add gpg-signatures to a p2-repo that's not necessary as it can used the ASCII-armored keys directly:
https://tycho.eclipseprojects.io/doc/4.0.10/tycho-gpg-plugin/sign-p2-artifacts-mojo.html#secretKeys
But from a quick look at the Tycho plugin it looks like that it does much more than the maven-gpg-plugin:
- https://maven.apache.org/plugins/maven-gpg-plugin/sign-and-deploy-file-mojo.html
- https://github.com/eclipse-tycho/tycho/tree/main/tycho-gpg-plugin/src/main/java/org
With the recommendation to use an environment variable, do you suggest to read the key-file content into an environment variable and specify it's name in the keyEnvName property of the gpg-plugin?
Can that work because that also expect the key in TSK-format. Btw. what format are the key-files exactly in respectively what's the name for it? Is it just ASCII-armored?
There was a problem hiding this comment.
I have just added passphrase:
secret-subkeys-jdt.asc-passphraseandsecret-subkeys-pde.asc-passphraseThank you. While testing the new passphrases I noticed that for the existing passphrase variable the name (probably) has a typo:
secret-subkeys-releng.acs-passphraseshould probably besecret-subkeys-releng.asc-passphrasesoascinstead ofacs. Could you please add a copy with a fixed name. I can then also adapt the other references to that secret.
@heurtematte or @fredg02 could you please help with that? It would be nice to have this unified.
There was a problem hiding this comment.
Thank you! The existing jobs have been adapt via:
| @@ -153,7 +149,7 @@ pipeline { | |||
| set -x | |||
|
|
|||
| ${MVND} -f eclipse-parent-pom.xml -s ${SETTINGS} \\ | |||
| gpg:sign-and-deploy-file -DretryFailedDeploymentCount=5 \\ | |||
| gpg:sign-and-deploy-file -Dgpg.signer=bc -DkeyFilePath=${KEYRING} -DretryFailedDeploymentCount=5 \\ | |||
There was a problem hiding this comment.
@laeubi or @merks can you tell if only the tycho-gpg-plugin can handle the ASCII armored key files directly or if the maven-gpg-plugin can handle them directly as well when using Bouncy castle?
Because currently it seems not to work, not even for platform where the passphrase is already available. Or maybe I have configured this wrong.
Maybe you can also help with the last question in https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/pull/2731/files#r1904755088
There was a problem hiding this comment.
All I can do is point at this which does pgp signing with bouncycastle:
Passing the 'MAVEN_GPG_PASSPHRASE' as environment variable fixes many build warnings: ''' [WARNING] Do not store passphrase in any file (disk or SCM repository), [WARNING] instead rely on GnuPG agent or provide passphrase in [WARNING] MAVEN_GPG_PASSPHRASE environment variable for batch mode. ''' Additionally using the Bouncy Castle (BC) signer is not only faster but also simplifies the setup as it can use the keyring in armored form and thus avoids the import step.
HannesWell
force-pushed
the
maven-signing-best-practices
branch
from
a728a75 to
78635bf
Compare
Passing the 'MAVEN_GPG_PASSPHRASE' as environment variable fixes many build warnings:
'''
[WARNING] Do not store passphrase in any file (disk or SCM repository),
[WARNING] instead rely on GnuPG agent or provide passphrase in
[WARNING] MAVEN_GPG_PASSPHRASE environment variable for batch mode.
'''
Additionally using the Bouncy Castle (BC) signer is not only faster but also simplifies the setup as it can use the keyring in armored form and thus avoids the import step.