Fix gpg signing during sonatype publishing to work with gpg versions: 2.1+

[pmellati]

Sets flag --pinentry-mode to loopback, to prevent gpg from interactively asking for
the gpg passphrase. This flag is necessary for newer versions of gpg.

The flag has been available in gpg since version 1.4.0 , so this patch should be compatible with gpg versions 1.4.0 and up.

See: https://www.gnupg.org/%28de%29/documentation/manuals/gpgme/Pinentry-Mode.html

[lefou]

We shouldn't hard code that at all. It could be a parameter to a sign command. I also think, that it should be possible to leave some defaults in a gnupg config file. Actually, I use the interactive default, when publishing non-automatically.

[lihaoyi]

So this is why I haven't managed to get non-interactive gpg signing to work. Looking forward to getting this merged

[pmellati]

@lefou As an immediate fix, I think it makes sense to hardcode this new parameter. It accomplishes the same purpose as the other pre-existing hardcoded parameter (i.e. --batch --yes).

If that's not an option, I can close this PR and work on another PR to make the gpg params configurable, but it will take more time.

[jodersky]

We shouldn't hard code that at all. It could be a parameter to a sign command. I also think, that it should be possible to leave some defaults in a gnupg config file. Actually, I use the interactive default, when publishing non-automatically.

I absolutely agree with @lefou here: gpg's config should only be handled by gpg, and never by the build tool. See this discussion in an issue in sbt-gpg. The gist of it is that key material may be provided in many different ways and that assuming the existence of a passphrase is already too restrictive (I'm using a yubikey for example).

As noted in the discussion, in case non-interactive signing is required (for example in CI), the recommended approach is to store the keychain itself in an encrypted format and remove the password from the GPG private key. See this section of sbt-gpg's readme on how this can be done.

[joan38]

We are basically not able to publish to sonatype from CI. I'm actually wondering how people have been doing so far.
How can we move forward on this? How can we set --pinentry-mode=loopback in config of gpg?

[jodersky]

We are basically not able to publish to sonatype from CI.

That hasn't been my experience. The way to do it is to not set a passphrase on the gpg key[1]. Then the pinentry flag is not even required.

[1] the reasons for not assuming passphrases are detailed in the discussion above and int linked sbt-gpg project. It essentially boils down to supporting to passphrase protection being a too strong assumption and not something that should be handled by mill

[jodersky]

Look at this how-to from sbt-gpg, it applies to mill as well. Here's an example ci build as well.

[joan38]

Ok I just saw the recommendation to remove the password from the key.

What makes --batch --yes hardcoded more legit over --pinentry-mode=loopback?
This publish target takes a --gpgPassphrase in argument we are obviously no looking for gpg to ask the passphrase on the standard input but rather take that passed from Mill. Isn't that right?
In what circumstances are we going to set --pinentry-mode to another mode?

[jodersky]

Hmm, didn't know there was this argument actually. Let me see

[joan38]

Any more opinions on this?

[jodersky]

The gpgPassphrase options seem to predate much of the discussion. I would actually suggest to remove them entirely.

What makes --batch --yes hardcoded more legit over --pinentry-mode=loopback?

It's a matter of assumptions and generalization. Who is to say that the key is a file protected with a passphrase in the first place? It could very well be in an HSM or obtained through some other mechanism.

The important thing to note is that we are using gpg to sign artifacts with a key. The passphrase is just an implementation detail about which mill should not concern itself. That is up to gpg.

[jodersky]

Wrt to removing the gpgPassphrase options, I actually think it would make sense to generalize them. Instead of having a "passphrase" option, why not create a parameter "gpg options" which gets passed verbatim to gpg? That should allow enough flexibility to accommodate all use cases.

[joan38]

Here is the implementation: #851

[lefou]

Fixed by #851

[Ammonite-Bot]

yay!

…

On Wed, 6 May 2020 at 4:21 PM, Tobias Roeser ***@***.***> wrote: Closed #753 <#753>. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#753 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE5HBDAGC4KUXTGFCH7Z2ELRQEMX7ANCNFSM4KB2SGXA> .