Support easier configuration for PGP signing

[merks]

In a free style job, PGP signing is configured like this:

Then there is a bunch of boilerplate stuff like this

gpg --batch --import "${KEYRING}"
for fpr in $(gpg --list-keys  --with-colons  | awk -F: '/fpr:/ {print $10}' | sort -u);
do
  echo -e "5\ny\n" |  gpg --batch --command-fd 0 --expert --edit-key $fpr trust;
done

# https://bugs.eclipse.org/bugs/show_bug.cgi?id=573866
mkdir -p ~/.gnupg
cat >> ~/.gnupg/gpg.conf <<EOL
use-agent 
pinentry-mode loopback
EOL
cat >> ~/.gnupg/gpg-agent.conf <<EOL
allow-loopback-pinentry
EOL
echo RELOADAGENT | gpg-connect-agent
echo "test" | gpg --clearsign --passphrase "${KEYRING_PASSPHRASE}"

But it's really easy to read the *.asc containing the secret keys with BouncyCastle directly. I expect that we can even just use the default key because I think there is only one. So with a command line option like -Dtycho.pgp.signer.bc.secretKeys=${KEYRING_PASSPHRASE} we should be able to do PGP signing without using gpg at all. The certainly works in my tests locally...

So in a pipeline, maybe we would only need to do this:

      steps {
        withCredentials([file(credentialsId: 'secret-subkeys.asc', variable: 'KEYRING')]) {
          withCredentials([string(credentialsId: 'gpg-passphrase', variable: 'KEYRING_PASSPHRASE')]) {
            sh '''
            mvn clean verify \
              -Dmaven.repo.local=$WORKSPACE/.m2/repository \
              -Psign -Pgpg-sign \
              -Dgpg.passphrase="${KEYRING_PASSPHRASE}" \
              -Dtycho.pgp.signer.bc.secretKeys=${KEYRING_PASSPHRASE}
              -Dproject.build.sourceEncoding=UTF-8 
            '''
          }
        }
      }

I'm not really sure we can confirm if this type of approach works on Eclipse infrastructure without first implementing it and trying it. But, as I said, this works for me locally....

[laeubi]

@merks do you mean Jenkins configuration in general? Because if we have an integration test that uses these two parameters (and a generated temporary key) then I think it should be safe...

[merks]

I can and definitely will create a unit test case for this scenario. Then when that's been built. I can try it out on a real build that works with the above type of scaffolding currently and then can be demonstrate to also work with this new simpler way. I'll work on a PR for this now.

[laeubi]

@merks by the way if you add a

Fix #<issue number>

to your commits this will automatically close issues once they are merged to master! (I assume #1726 has fixed this)

[merks]

@laeubi I didn't know that. That's helpful!

[laeubi]

You can read all the details here: https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue