Using useGpg with 1.1.1 fails with error about no public key found

[Katrix]

Upgrading sbt-gpg to 1.1.1 from 1.1.0 prevents me from creating any signed builds when setting useGpg to true.

[error] gpg: error checking usability status of D4FEF54C
[error] gpg: key D4FEF54C: secret key without public key - skipped
[error] gpg: no default secret key: No secret key
[error] gpg: signing failed: No secret key
[error] java.lang.RuntimeException: Failure running gpg --detach-sign.  Exit code: 2

My global configuration file looks like this

com.typesafe.sbt.SbtPgp.autoImport.useGpg := true
com.typesafe.sbt.SbtPgp.autoImport.pgpPublicRing := file("C:/Users/katri/AppData/Roaming/gnupg/pubring.gpg")
com.typesafe.sbt.SbtPgp.autoImport.pgpSecretRing := file("C:/Users/katri/AppData/Roaming/gnupg/secring.gpg")

My guess is that only the private keyring is passed to Gpg, and not the public one.

[djspiewak]

Private keyrings cannot be passed to GPG. It is actually not allowed by the command line interface.

[Katrix]

I know for certain I've used it with GPG before though and it worked. Currently using gpg 2.0.<something I can't remember here>

[Adowrath]

I can confirm this happening to me as well. When using sbt-pgp version 1.1.1 and gpg 2.2.3, publishLocalSigned fails with:

[error] gpg: no default secret key: Kein geheimer Schl?ssel
[error] gpg: signing failed: Kein geheimer Schl?ssel
[error] gpg: no default secret key: Kein geheimer Schl?ssel
[error] gpg: signing failed: Kein geheimer Schl?ssel

(the 'Kein geheimer Schl?ssel' means essentially "No secret key").

The only settings I have is useGpg := true and the standard global addSbtPlugin statement. Interestingly, pgp-cmd list-keys lists C:\Users\Adowrath\.gnupg\pubring.gpg as its file and no keys, but gpg --list-keys lists C:\Users\Adowrath\AppData\Roaming\gnupg\pubring.kbx with the usual key.

When I downgrade to sbt-pgp to 1.1.0, changing nothing else, publishLocalSigned works just as expected, opening the window to enter my passphrase and all. When I have time later this or next week, I might try to find the bug-introducing commit!

[Adowrath]

18a383a3adfc9eeb5aa2ddd3a8c86d2ce80b33fe seems to be the culprit here, at least when bisecting the commits specific to 1.1.1. When changing this line in the CommandLineGpgSigner to an empty Seq(), all works well. This suggests that the default secret ring is not correct - as evident in my earlier post.

By setting the value of pgpSecretRing to the .kbx file, the command works. However, that shouldn't work, if I understood #126 correctly at least, and even so, it should be documented. Either way, the .kbx vs. .gpg detection in PgpSettings is broken for me as well - despite using gpg and thus gpgAncient being false, the .gpg files are chosen. And still, they are in the wrong folder - Gpg4win installed its database in AppData by default.

Whether the user should be made to manually configure or the implementation should be made Gpg4win aware is up to you, of course.

[mpilquist]

Just ran in to the same issue when upgrading scodec from sbt-pgp 1.1.0 to 1.1.1 (and using useGpg := true)

[djspiewak]

I think the solution here is to do the more aggressive rewrite that I was talking about in #126, effectively removing support for Bouncycastle entirely, delegating uniformly to gpg-agent, etc. The current configuration scheme is just incompatible with recent versions of GPG (by which I mean, less than five years old). We can keep patching and hacking our way past things, but ultimately I don't think we're going to be able to keep the current configuration schema and solve the Venn diagram of:

• Local split subkeys (e.g. YubiKey signing)
• Strong (read: functional) default modes
• On-CI encrypted private keys
• Cross-platform compatibility

I would consider those four points, at a minimum, to be requirements. One of them (split subkeys) is hard-incompatible with Bouncycastle, while the latter two are incompatible with GPG under the current configuration scheme (which favors Bouncycastle).

So tldr, we really need to break compatibility here, or start bailing for https://github.com/jodersky/sbt-gpg

[andyscott]

This issue with sbt-pgp prompted me to switch to https://github.com/jodersky/sbt-gpg, per @djspiewak's suggestion.

For what it's worth, I've found sbt-gpg to be extremely easy to use. It's quite a bit more intuitive than sbt-pgp-- so I intend to use @jodersky's plugin going forward.

[eed3si9n]

Nice. I for one would be happy to see the community migrate to sbt-gpg, compared to the current situation we are in with sbt-pgp.

[andyscott]

If we want to trial-- and ultimately encourage-- a migration: should we politely offer to maintain https://github.com/jodersky/sbt-gpg under https://github.com/sbt or another "community" organization?

Aside: this discussion might be better off in another ticket :).

[eed3si9n]

As a starter, I opened https://github.com/sbt/sbt-pgp/issues/140.