Could we please merge it to the stable branch (2.2.3 does not have this patch yet) or it is not tested enough? Existing subkey sellection strategy doesn't play well with mail signing and affects GPGTools/GPGMail users as well as any other users with multiple signing subkeys. Thanks!

Please do not post warning. They are called warnings for a reason.

Nevermind, I did not realize that passwd does not only operate on the selected key but on all keys (subkeys) in sequence.

I tried to remove the passphrase on my authentication subkey but the same issue seems to still be present in version 2.2.2.

Applied to 2.2 branch.

This has been fixed a while ago my having dirmngr print a hint on the possible problem. gpg will then print a warning about a problem with the Tor configuration and with --verbose print the hint on solving this as well.

Ok for me to just have it in master. It should be fixed but is not super important imo.

Hmm. I am fine changing this for master. But for 2.2 I am nut sure. Asking on gnupg-devel?

I confirmed this is same bug in T2923: trust signature domain restrictions don't work, I am closing this one as duplicate.

OK, closed.

I close this for now. If you run into problems with 2.2.2 again, please re-open this bug.

Unfortunately --batch option doesn't help, it only suppresses user input.

$ gpg2 --pinentry-mode loopback --batch --delete-secret-keys F4433F96910C9AC1FEF65A7299A5538C769B6150
gpg: deleting secret key failed: No pinentry
gpg: deleting secret subkey failed: No pinentry
gpg: F4433F96910C9AC1FEF65A7299A5538C769B6150: delete key failed: No pinentry

GPG pinentry works well on my Gnome desktop (wellformated form appear) but I have a problem when I need remove secret key (enter passphrase) on remote machine via SSH.
It can be handled with --export why not with --delete-secret-keys?
Is there some fix already? Or roadmap this will be fixed? Or some workaround how can I remove secret key remotely via SSH?

gpg-agent sometimes pops up confirmation dialogs. This can't yet be handled with the loopback pinentry. Try gpg option --batch.

Same issue exists in 2.2:

The long term goal is to replace sshcontrol by aflag in the extended private key format. This would instantly solve the bug. Thus closing.

A backport to 2.0 does not make anymore sense given EOF in 2 months.

gniibe: Can you check the status?

Won't be fixed for 1.4.

2.0 reached eol in 2 months so need to check it. For 1.4 I assume it has been fixed ;-)

@perske, may I ask you to send a DCO and an possible updated patch against 2.2 to gnupg-devel@ ? I would like to add it to 2.2.2. Sorry for the delays.

There should be a backup file in these cases.

In 2.2 we implemented --import-option show-only which dies the right thing, that is to use the reguarl key-listing code. Backporting this to 1.4 does not make sense - people should move on and use gpg 2.2.

Given that we received no info after nearly two years, shouldn't we simply assume that this bug as been fixed?

gnupg 2.1.11 is pretty old and has quite some bugs. Please try at least the Debian version which is 2.1.18 plus a couple of backported fixes. Or yet better, the current stable 2.2.x

Backport to 2.2 done.

Fixed in master. Backport to 2.2 pending.

Potentially useful to know: This is how the import looks like into an empty ~/.gnupg directory:

Looking again at this case I assume this problem is seen more often today because 2.1 started to clean keys during import. That enlarges the time span for the race condition. We clearly need to do something about this in gnupg 2.2.

We need a way to delete a secret subkey.

No direct way. You can do this:

Ooops. you meant a subkey - let me check...

Sure: --delete-secret-and-public-key FINGERPRINT

OK, sorry. Forgive me to ask here.. but is there a way how to remove both - the public and the private part? - and only of a specific subkey?

That is intended.

Werner, so what do you suggest? Does Enigmail (and any other tool using gpg, and actually also across tools) need to make sure that there are no concurrent calls to gpg of the type that could lead to adding a new key in the keyring?

Ok, thanks for the explanation.

When Enigmail is running several operations at the same time it is possible that this happens. We would need to take a read lock for the entire time it takes to fetch the key or use other complicated methods to avoid a test/insert race. That would be very inconvenient. The proposed solution is to have just one process to update the keyring.

Because of policy requirements I have.

Fixed in master, applying D297: 785_sign-fix.patch.
If needed, it will be in stable 2.2 branch, in future.

What is the benefit of two subkeys?

No info received and thus assuming that the caching was disabled.

It is on the same machine, as I mentioned manually deleting ~/.gnupg/private-keys-v1.d/* is a workaround I have to use, but it is not very user friendly.

Sorry previosly I asked for more slots for keys on token. But its not
needed one. I dont even know it is a valid request but

GnuPG by design uses latest sub keys so in your setup office and home one
of them is latest.

The use case is having 2 different hardware tokens - I have an opengpg card which supports 4096 rsa subkeys, and a yubikey which supports 2048 rsa subkeys. At work I need one, at home the other.

After reading PIV and using PIV token I understood how much simple and easy
GnuPG is by design. You guys rock.

Is it you are moving to new sub keys? if yes do we still need outdated old
subkeys? Is it safe to cleanup old subkeys?

Hi, currently to be able to use 2 different cards with 2 different sets of subkeys from the same primary key (home and work) I need to manually delete ~/.gnupg/private-keys-v1.d/* everytime I want to switch from the first card to the second.

@bluca I created a ticket for smartcard, so that this ticket can focus on the issue of available keys on host. If anything, please add comment to T3416: gpg should select available signing key on card (even with -u option).

@gniibe yes, I can reproduce the problem using -u.
But why does picking a UID force the usage of the first known subkey? Is that expected behaviour? Is there a relationship between UIDs and subkeys?

I have updated D297: 785_sign-fix.patch patch to minimize the impact only to secret key lookup.

My change only addressed the use case with smartcard. So, I removed [TESTING] tag.

Now, 2.1.22 or later supports automatic selection of secret key by available key on card.
Closing.

My pleasure.

Thanks.

Updated translation el.po file from latest commit in gnupg repo.

This error appears in versions 2.1.15 to 2.2.0 on all platforms.