1

I'm using Debian-based Docker image, and I have only one usable key in the keyring:

$ gpg -K
/tmp/test-keyring/pubring.kbx
-------------------------------
sec>  rsa2048 2012-01-16 [C] [expires: 2024-05-15]
      CB522FE0379DDF40A93400D7E4BC91FACDA9A65B
      Card serial no. = 00nn 00nnnnnn
uid           [ unknown] John Doe <username@example.com>
ssb#  rsa2048 2012-01-16 [S] [expires: 2024-05-14]
ssb   rsa3072 2012-01-16 [S] [expires: 2024-05-15]

As you can see here, there are three keys:

  • Primary key tagged with > resides on the smart card. It is marked as certify-only key, therefore it can't be used for signing.
  • Private part for the second secondary signing key, tagged with #, isn't present here. Therefore it can't be used for signing.
  • Third secondary signing key has a private part available. This is the only key here that can be used for signing.

Again, last key here is the only key usable for signing purposes.

Alas, for some reason GnuPG fails to see it:

$ echo test | gpg --clearsign
gpg: no default secret key: Unusable public key
gpg: [stdin]: clear-sign failed: Unusable public key

Yet has no problem signing if I specify a user ID directly:

$ echo test | gpg --clearsign --default-key username@example.com
gpg: using "username@example.com" as default secret key for signing
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

test
-----BEGIN PGP SIGNATURE-----

The manual says it should be working out of the box:

--default-key name Use name as default user ID for signatures. If this is not used the default user ID is the first user ID found in the secret keyring.

I'm using GnuPG 2.2.19:

$ gpg --version
gpg (GnuPG) 2.2.19
libgcrypt 1.8.5

I've applied a known Docker workaround with GPG_TTY, to no avail.

What do I do to make it work?

  • Just a guess, but the issue may be that the trust status of the key is “unknown”. Try setting the trust to “ultimate” with gpg --edit-key username@example.com and then trust. – tastytea Feb 16 at 15:32
  • @tastytea it wasn't that :( – sanmai Feb 16 at 15:52
0

You can put default-key username@example.com or default-key CB522FE0379DDF40A93400D7E4BC91FACDA9A65B into ~/.gnupg/gpg.conf to work around the issue.

| improve this answer | |
0

If I'm reading this right: you have two subkeys for signing but one is offline:

ssb#  rsa2048 2012-01-16 [S] [expires: 2024-05-14]
ssb   rsa3072 2012-01-16 [S] [expires: 2024-05-15]

I would expect to see: ssb> on both, which confirms that the subkeys have been replaced by stubs. That might be why gnupg is confused.

From the same source:

The # indicates that the private key for that key is not available at all. This is the case with off-line master keys.

My setup is something like this with 3 subkeys for Signing, Encrypting and Authentication. Note that all 3 subkeys reside on a smart card:

sec#  rsa4096 2011-01-15 [C]
      xxxxxxxxxxxxxxxxxxxx
uid           [ unknown] xxxxxxxxxxxxx
ssb>  rsa4096 2011-01-15 [S]
ssb>  rsa4096 2011-01-15 [E]
ssb>  rsa4096 2011-01-15 [A]

I am wondering if the smart card was in the reader when you attempted the sign operation.

| improve this answer | |
  • It was, and it started working as it should once I get the card removed. I have one subkey residing locally, that's why it isn't marked with > or #. And that's probably why signing still works if I remove the card. Thank you for asking. – sanmai Feb 17 at 1:12
0

The problem disappears if I happen to unplug the smart-card, and repeat signing operation. This was a GnuPG bug, and it appears that it is going to be fixed in the next release.

Dockerized environment has nothing to do with this.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.