[MGPG-90] Signing fails with 3.0.1: "no pinentry"

[jira-importer]

Jens Reimann opened MGPG-90 and commented

Starting with 3.0.1 performing a maven release fails in the process of signing artifacts with the message: "gpg: no pinentry".

I do believe this is due to the fact that in non-interactive mode with a newer gpg version, the gpg plugin forces a "pinentry error" if no pin is provided. And the release plugin runs the gpg plugin in non-interactive mode

However, not everyone wants to store the pin in a configuration file. Assuming you have an interactive release process, you also might want an interactive pin entry.

I would suggest to allow the user to force the pin entry to interactive (not matter what the current maven context says). That way, you can keep the current behavior, but still allow a manual/interactive release process.

---

Affects: 3.0.1

Issue Links:

• MRELEASE-1114 Broken interaction of maven-gpg-plugin with Gpg4win Kleopatra since 3.0.0-M6
  ("is caused by")
• MGPG-84 signing fails in eclipse when using gpg-agent

4 votes, 14 watchers

[jira-importer]

Michael Osipov commented

There is an open issue somewhere, I remember the problem field.... sjaranowski, do you remember?

[jira-importer]

Slawomir Jaranowski commented

The source of problem can be in: MSHARED-1072
m-release-p use cmd executor form m-shared-utils and until MSHARED-1072 there is no possibility to execute subprocess in interactive mode by m-release-p

I have added to my ~/.gnupg/gpg.conf (on macOs)

use-agent

and don't see such issue.

Another workaround you can try set mavenExecutorId parameter of m-release-p to value: forked-path,
then m-release-p will use old implementation of executor ForkedMavenExecutor, but this use plexus-utils .... which is copy paste somewhen of m-shared-util ( or shared-utils code was copied from plexus ...)

[jira-importer]

Hervé Boutemy commented

the real issue is maven-release-plugin version used: see MRELEASE-1114

the workaround is to run mvn gpg:sign to init the GPG agent, then run again mvn release:perform
see MRELEASE-1114 for more details

[jira-importer]

Slawomir Jaranowski commented

Aftre MRELEASE-1091 forked process is always executed in batch mode it cause to execute gpg with params like:

gpg --sign --armor --no-tty --batch --pinentry-mode error -v  pom.xml

Interesting and not understood for me

$ killall gpg-agent

$ gpg --sign --armor --no-tty --batch --pinentry-mode error -v  pom.xml
gpg: enabled compatibility flags:
gpg: no running gpg-agent - starting '/usr/local/Cellar/gnupg/2.4.0/bin/gpg-agent'
gpg: waiting for the agent to come up ... (5s)
gpg: connection to the agent established
gpg: using pgp trust model
gpg: using "84789D24DF77A32433CE1F079EB80E92EB2135B1" as default secret key for signing
gpg: writing to 'pom.xml.asc'
gpg: signing failed: No pinentry
gpg: signing failed: No pinentry

$ ps ax | grep gpg-agent
45871   ??  Ss     0:00.00 gpg-agent --homedir /Users/slawomir.jaranowski/.gnupg --use-standard-socket --daemon

gpg-agent was launched but cannot be used

next run doesn't to try to execute gpg-agaent

$ gpg --sign --armor --no-tty --batch --pinentry-mode error -v  pom.xml
gpg: enabled compatibility flags:
gpg: using pgp trust model
gpg: using "84789D24DF77A32433CE1F079EB80E92EB2135B1" as default secret key for signing
gpg: writing to 'pom.xml.asc'
gpg: signing failed: No pinentry
gpg: signing failed: No pinentry

so try workaround:

$ echo "test" | gpg --clearsign -v
gpg: enabled compatibility flags:
gpg: using pgp trust model
gpg: using "84789D24DF77A32433CE1F079EB80E92EB2135B1" as default secret key for signing
gpg: writing to stdout
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


test
gpg: pinentry launched (59458 mac 1.1.1 - xterm-256color /private/tmp/com.apple.launchd.dqruVX8Tfe/org.xquartz:0 - 604932503/1262638422 0)
gpg: RSA/SHA256 signature from: "0x9EB80E92EB2135B1 Slawomir Jaranowski <.....>"
-----BEGIN PGP SIGNATURE-----


iQIzBAEBCAAdFiEEhHidJN93oyQzzh8HnrgOkushNbEFAmRVYagACgkQnrgOkush
... 

old gpg-agent was used - BUT also pinentry was used

and finally:

$ gpg --sign --armor --no-tty --batch --pinentry-mode error -v  pom.xml
gpg: enabled compatibility flags:
gpg: using pgp trust model
gpg: using "84789D24DF77A32433CE1F079EB80E92EB2135B1" as default secret key for signing
gpg: writing to 'pom.xml.asc'
gpg: RSA/SHA256 signature from: "0x9EB80E92EB2135B1 Slawomir Jaranowski <....>"

next test:

$ killall gpg-agent
$ rm pom.xml.asc 
$ gpg --sign --armor --no-tty --batch --pinentry-mode default -v  pom.xml
gpg: enabled compatibility flags:
gpg: no running gpg-agent - starting '/usr/local/Cellar/gnupg/2.4.0/bin/gpg-agent'
gpg: waiting for the agent to come up ... (5s)
gpg: connection to the agent established
gpg: using pgp trust model
gpg: using "84789D24DF77A32433CE1F079EB80E92EB2135B1" as default secret key for signing
gpg: writing to 'pom.xml.asc'
gpg: pinentry launched (64536 mac 1.1.1 /dev/ttys000 xterm-256color /private/tmp/com.apple.launchd.dqruVX8Tfe/org.xquartz:0 20620/604932503/4 604932503/1262638422 0)
gpg: RSA/SHA256 signature from: "0x9EB80E92EB2135B1 Slawomir Jaranowski <...>"

gpg-agent was lanched and pinentry was used first time

so now I can:

$ rm pom.xml.asc
$ gpg --sign --armor --no-tty --batch --pinentry-mode error -v  pom.xml
gpg: enabled compatibility flags:
gpg: using pgp trust model
gpg: using "84789D24DF77A32433CE1F079EB80E92EB2135B1" as default secret key for signing
gpg: writing to 'pom.xml.asc'
gpg: RSA/SHA256 signature from: "0x9EB80E92EB2135B1 Slawomir Jaranowski <...>"

even more with --pinentry-mode default - pinentry is not used second time

$ rm pom.xml.asc
$ gpg --sign --armor --no-tty --batch --pinentry-mode default -v  pom.xml
gpg: enabled compatibility flags:
gpg: using pgp trust model
gpg: using "84789D24DF77A32433CE1F079EB80E92EB2135B1" as default secret key for signing
gpg: writing to 'pom.xml.asc'
gpg: RSA/SHA256 signature from: "0x9EB80E92EB2135B1 Slawomir Jaranowski <...>"

[jira-importer]

Slawomir Jaranowski commented

So even we fix possibility to execute forked process in interactive mode by m-resolver-p problem we still exists if  we want to use batch mode for release

and one more test:

$ killall gpg-agent
$ mvn gpg:sign -B
...
[INFO] --- gpg:3.0.1:sign (default-cli) @ mrelease-1114 ---
gpg: using "84789D24DF77A32433CE1F079EB80E92EB2135B1" as default secret key for signing
gpg: signing failed: No pinentry
gpg: signing failed: No pinentry
...

$ mvn gpg:sign
...
[INFO] --- gpg:3.0.1:sign (default-cli) @ mrelease-1114 ---
gpg: using "84789D24DF77A32433CE1F079EB80E92EB2135B1" as default secret key for signing
...

$ mvn gpg:sign -B
...
[INFO] --- gpg:3.0.1:sign (default-cli) @ mrelease-1114 ---
gpg: using "84789D24DF77A32433CE1F079EB80E92EB2135B1" as default secret key for signing
...

 

[jira-importer]

Hervé Boutemy commented

reading your analysis/tests, I feel that --pinentry-mode error parameter seems too aggressive: even with no tty, we expect to have a pin-entry by the gpg agent, isn't it? (I'm not an expert, far from that...)

looking at source code https://github.com/apache/maven-gpg-plugin/blame/master/src/main/java/org/apache/maven/plugins/gpg/GpgSigner.java#L128
this has been added in MGPG-79 #9

[jira-importer]

Michael Osipov commented

We can only expect then entry when an interactive user runs a non-interactive session. on CI nodes this will just block the process forever.

[jira-importer]

Łukasz Dywicki commented

I believe that I've ran into this one with github actions executing maven-gpg-plugin 3.0.1 under maven release plugin 3.0.1. I've tried also maven-gpg-plugin 3.1.0, but it failed too. I've had to revert to release 3.0.0-M6 in order to conduct proper maven release, is there any workaround available to battle this incompatibility?

[jira-importer]

Tamas Cservenak commented

3.2.0 is on vote, it contains Java (Bouncy Castle) based signer, so nothing needed on CI, just provide key (in TSK) and passphrase as "secrets" in form of env variables and you are free to go.

See here https://maven.apache.org/plugins-archives/maven-gpg-plugin-LATEST/examples/deploy-signed-artifacts.html#sign-using-bc-signer

Tested on GH and did deploy successfully signed artifacts to oss.sonatype.org

[jira-importer]

Gotson commented

We encountered the same issue when bumping the plugin from 3.1.0 to 3.2.0.

The CI run in Github Action failed with "gpg: signing failed: No pinentry" while it worked fine with 3.1.0: https://github.com/xerial/sqlite-jdbc/actions/runs/8242646044/job/22542143407#step:10:73

[jira-importer]

Tamas Cservenak commented

As I see you use env variable {}MAVEN_CENTRAL_GPG_PASSPHRASE{}.

According to doco https://maven.apache.org/plugins/maven-gpg-plugin/sign-mojo.html#passphraseEnvName

It is MAVEN_GPG_PASSPHRASE so basically the plugin does not find it, and would ask for it, but cannot in batch mode => failure.

[jira-importer]

Tamas Cservenak commented

You can also remove the loopback thing from config. How do you make keys be in place? As you could try out BC signer, as GnuPG leaves keys in ~/.gnupg directory...

To use BC signer, you need to define another secret, as env MAVEN_GPG_KEY with key material in TSK format (basically the gnupg export).

[jira-importer]

Tamas Cservenak commented

Created PR xerial/sqlite-jdbc#1082

[jira-importer]

Gotson commented

The environment variables are set by the setup-java step, so the default does not apply. The matching environment variables are then set in the deploy step.

It works fine in 3.1.0, but starts failing in 3.2.0, while nothing else has changed, so i suppose there's something that changed in 3.2.0 for it to fail now.

[jira-importer]

Antonin Delpeuch commented

Thanks for the example PR Tamas, we ran into this issue when upgrading from 3.1.0 to 3.2.0. Looking at the release notes I could not really understand why, because it looked like the "best practices" mode was opt-in.

It could be useful to adjust the release notes (for instance, editing the GitHub release) to make it clear that an adaptation is required on the user's side, no?

This is my attempt to fix the problem on our side:

https://github.com/OpenRefine/OpenRefine/pull/6439/files