[
https://issues.apache.org/jira/browse/MGPG-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17825593#comment-17825593
]
Tamas Cservenak edited comment on MGPG-90 at 3/12/24 9:37 AM:
--------------------------------------------------------------
Best practices ARE opt-in.
I am pretty confident nothing changed (will doublecheck) in GnuPG signer, as
this issue was reported against 3.0.1 but also 3.1.0 (and [~gotson] just
confirmed it). So, my guess is that we deal with some changes happened not in
this plugin, but in setup-java GH action?
Anyway, ideally one should NOT rely on setup-java (it should really do ONLY
what it's name implies: "setup java"), as now GPG plugin can receive key
material and passphrase via env variables (that is trivial to set up as
"secrets" in GH repo).
On CI env it is warmly recommended to NOT rely on GnuPG executable, as on
Windows worker you even need to (re)install it, as present one is defunct, see
[https://github.com/apache/maven-gh-actions-shared/commit/45f4617ba01c4be9dca576ff755f548127e76086|https://github.com/apache/maven-gh-actions-shared/commit/45f4617ba01c4be9dca576ff755f548127e76086.]
Moreover, it needs hoops and loops, like not only install, but import the key
(I guess done by setup java), sign (via custom settings.xml that uses
{{env.XXX}} in servers), and finally, it leaves your key on disk.
Best to do, is to use BC signer, and set up key and passphrase as env
variables, no fuss, no leaks.
was (Author: cstamas):
Best practices ARE opt-in.
I am pretty confident nothing changed (will doublecheck) in GnuPG signer, as
this issue was reported against 3.0.1 but also 3.1.0 (and [~gotson] just
confirmed it). So, my guess is that we deal with some changes happened not in
this plugin, but in setup-java GH action?
Anyway, ideally one should NOT rely on setup-java (it should really do ONLY
what it's name implies: "setup java"), as now GPG plugin can receive key
material and passphrase via env variables (that is trivial to set up as
"secrets" in GH repo).
On CI env it is warmly recommended to NOT rely on GnuPG executable, as on
Windows worker you even need to (re)install it, as present one is defunct, see
[https://github.com/apache/maven-gh-actions-shared/commit/45f4617ba01c4be9dca576ff755f548127e76086|https://github.com/apache/maven-gh-actions-shared/commit/45f4617ba01c4be9dca576ff755f548127e76086.]
Moreover, it needs hoops and loops, like not only install, but import the key
(I guess done by setup java), sign (via custom settings that uses {{env.XXX}}
in servers, and finally, it leaves your key on disk.
Best to do, is to use BC signer, and set up key and passphrase as env
variables, no fuss, no leaks.
> Signing fails with 3.0.1: "no pinentry"
> ---------------------------------------
>
> Key: MGPG-90
> URL: https://issues.apache.org/jira/browse/MGPG-90
> Project: Maven GPG Plugin
> Issue Type: Bug
> Affects Versions: 3.0.1
> Reporter: Jens Reimann
> Priority: Blocker
>
> 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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
