useGpg := true results in incorrect --keyring parameter

[djspiewak]

Currently it appears that setting useGpg := true (which is the only option if you use a signing subkey due to Bouncycastle bugs) results in passing the --keyring parameter to the gpg executable with the secret keyring as the parameter. This is incorrect as of GPG 2.1 (which is quite old now). --keyring should generally be avoided altogether, but if you're going to use it, the value passed must be the public keyring. There is no option to pass a secret keyring.

Instead, if you wish to override the location of secret keys, you need to use the --homedir option, which in turn changes the parent directory in which gpg will look for the private-keys-v1.d/ subdirectory, which is where the private keys reside.

There doesn't appear to be a good way to resolve this issue as a user except for setting pgpSecretRing := pgpPublicRing.value, since this is the only correct instantiation at any rate.

This gets into a broader series of issues with sbt-pgp as a whole, since obviously gnupg is just using a completely different keyring format than what Bouncycastle is going to expect out of the box. Between this and the fact that Bouncycastle doesn't support split subkeys (which is unambiguously the best practice for managing GPG keys), it really seems like the right long-term solution here would be to (incompatibly!) remove the Bouncycastle support and revise the setting keys to correspond with gnupg's post-2.1 schema.

[jodersky]

I also ran into these limitations quite recently and built my own plugin that exclusively relies on gpg (and is intended to delegate all operations to gpg-agent). If that portability trade-off works for you, you could try out https://github.com/jodersky/sbt-gpg

[djspiewak]

@jodersky This is really interesting. I'm not sure I agree with falling back to default functionality when gpg/keys aren't available (I would rather see it fail outright), but I can see why that would be the default. I'm also slightly concerned about how fiddling with publish will interact with plugins like sbt-bintray, though I love the fact that it removes the "unsigned publish" option and obviates the need to call publishSigned.

Anyway, will investigate further. Thanks for the pointer!

[eed3si9n]

Fixed in https://github.com/sbt/sbt-pgp/pull/131?

[steinybot]

I don't think #131 fixes this.

[huntc]

Should the documentation be updated to avoid recommending the setting of useGpg entirely?

"add useGpg := true to your build.sbt to make the plugin gpg-aware"

I've just removed that setting and I'm back in business having followed the above guide.

[djspiewak]

@huntc Bouncycastle doesn't support post 2.1-style GPG keyrings. It supports certain forms of exported keys, but not the keyrings themselves. If you generated your keys a million years ago, it will still work, but it won't work with anything recent (I think GPG 2.1 is like, 5 years old now). So this is why the useGpg := true setting is recommended.

Frankly, I would honestly recommend using sbt-gpg instead of sbt-pgp. And that's absolutely no aspersions to the authors or maintainers of this plugin, it's just that sbt-gpg handles a lot of these cases a lot more smoothly and has the benefit of a cleaner design (since it's solving a simpler problem and was never written to work on an ancient version of SBT).

[huntc]

Thanks for the background @djspiewak.

The problem we presently have is that the documentation is presently incorrect and I think we should correct it. I'm happy to raise the PR, but I need to understand what to doc. Sounds like sbt-gpg is the go.