How to force maven-gpg-plugin to use primary gpg key instead of a sub key?

Question

I have a GPG public key with a sub key. When I attempt to sign my Maven artifacts as part of the release process, the plugin is signing with the sub key instead of the main key.

Looking at the docs for the plugin here: http://maven.apache.org/plugins/maven-gpg-plugin/sign-mojo.html

I do not see an obvious property to set to control which key is used. Is it possible to control this?

Answer 1

TLDR; You can control it by deleting or revoking the subkey. Revoking is recommended.

--

This has been discussed in this sonatype issue, for example. Also, it doesn't only impact the UI - I created my keys using gpg4win on windows 7, and command line key generation generated both pub and subkeys:

> gpg --gen-key

> gpg --list-keys

pub   2048R/xxxxxxxx 2014-12-18
uid       
sub   2048R/yyyyyyyy 2014-12-18

Comments say that you have two options:

you will want to delete the sub key, and then sign, deploy again

..

I revoked the key (did not delete it) and that worked as well.

The comments in the issue say that the document was updated regarding instructions, but link no longer works. By using some page caches I was able to salvage the content, which read like this:

Delete a Sub Key

Some PGP tools by default generate a sub signing key and use it for signing instead of using the primary key. This is a problem if you use it to sign artifacts and deploy artifacts to the Central Repository, because Nexus could not get the primary key ID from a signature produced by sub key, thus it could not import the public key and will fail to verify the artifact. The fix is to delete the sub signing key so PGP will use the primary key for signing.

To get an idea weather you have a sub signing key, run command below with your own key ID:

$ gpg --edit-key A6BAB25C

gpg (GnuPG/MacGPG2) 2.0.17; Copyright (C) 2011 Free Software
Foundation, Inc. This is free software: you are free to change and
redistribute it. There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

pub  2048R/A6BAB25C  created: 2011-08-31  expires: 2012-06-26  usage: SC
                       trust: ultimate      validity: ultimate
sub  2048R/DD289F64  created: 2011-08-31  expired: 2011-09-30  usage: E
sub  2048R/8738EC86  created: 2011-12-19  expires: 2012-06-16  usage: S
[ultimate] (1). Juven Xu (for testing) <test@juvenxu.com>

As you can see from above example, this key has 2 sub keys with ID DD289F64 and 8738EC86. The output also shows the creation time and expiration time. What's important here is usage: E stands for Encryption so sub key DD289F64 is used for encryption only, S stands for Signing so sub key 8738EC86 is used for Signing only. If a primary key has a S sub key, it will use it for signing, otherwise itself will do signing job. So we want to delete the sub key 8738EC86.

First select the sub key we want to delete, since its index is 2 (indices starts with 0), we run command:

gpg> key 2

pub  2048R/A6BAB25C  created: 2011-08-31  expires: 2012-06-26  usage: SC
                       trust: ultimate      validity: ultimate
sub  2048R/DD289F64 created: 2011-08-31  expired: 2011-09-30  usage: E
sub* 2048R/8738EC86 created: 2011-12-19  expires: 2012-06-16  usage: S
[ultimate] (1). Juven Xu (for testing) <test@juvenxu.com>

As you can see from the output, the sub key 8738EC86 is marked with *. Now delete it:

gpg> delkey

Do you really want to delete this key? (y/N) y

pub  2048R/A6BAB25C  created: 2011-08-31  expires: 2012-06-26  usage: SC
                       trust: ultimate      validity: ultimate
sub  2048R/DD289F64  created: 2011-08-31  expired: 2011-09-30  usage: E
[ultimate] (1). Juven Xu (for testing) <test@juvenxu.com>

Tip If you've already distributed your public key, it's better to revoke the sub signing key instead of deleting it, although either way you can make your primary key as the signing key. See the The GNU Privacy Handbook for the difference between deleting and revoking. To revoke a sub key, use gpg> revkey instead of gpg> delkey.

Ya! 8738EC86 is not listed any more, the final step is saving our change:

gpg> save

That's it! Now you can test the change by signing a file, and then verify it. The output should contain something like:

gpg: Signature made ************************* using *** key ID [YOUR-PRIMARY-KEY-ID]

So, for me the practical steps were

gpg --edit-key PRIMARYKEYID
key 1
revkey
[y]
[3]
save

and redoing the sign/release.

Answer 2

After asking some questions on mailing lists, it appears I wasn't the only one with this issue.

In my case, I had created my key pairs using GPG Keychain Access UI on my Mac. Other users who had used the same tool to create their keys also reported the same issue with Maven.

For whatever reason, when you create a key pair using that UI it creates not only a top level key but also a sub key. This doesn't happen when you use the command line tools to create a new keypair.

So I went to the command line, revoked the subkey and everything started to work.

I am not sure if the underlying issue is with the way the GPG KeyChain Access UI creates keys, or if it is the way the maven plugin reads keys though.