In T2291#140172, @gniibe wrote:

Thank you for testing.
For the issue #1, I think it is the probelm of rG1cd615afe301: gpg,card: Allow no version information of Yubikey.. This was introduced by the support of PIV feature of Yubikey.

Thank you for testing.
For the issue #1, I think it is the probelm of rG1cd615afe301: gpg,card: Allow no version information of Yubikey., which is fixed already. This was introduced by the support of PIV feature of Yubikey.

Report on some testing using master:

See the release info over at T5052 which notes the problem. See T5140 for details and update to 2.2.25.

Backported.

We need another patch, because there are two places for gpg --card-edit and gpg-card to check OpenPGPcard's version number if it's >= 2 or not.

Perhaps of interest for this issue: the HKPS pool has consisted of only a single server for a couple of months now.

In T2291#139821, @lopter wrote:

if I am running master, it is now possible to have a setup where the same encryption key is shared by and usable from multiple smart cards?

Thank you for all the work! Does it mean that, if I am running master, it is now possible to have a setup where the same encryption key is shared by and usable from multiple smart cards?

Fixed in master. I will backport to 2.2.

This has been fixed for Unix on 2.2 and 2.3. The command line fix for Windows is a larger thing already tracked by T4398.

We changed the fallback to utf-8 in 2.2 and 2.3 and thus this bug can be closed. On Windows there is still the problem with the command line. However, this is better tracked with T5038 and its related tasks.

Finally, with the physical device, I figure out what's going on.
The error handling in bulk_in in ccid-driver.c is not good for pinpad input.
It doesn't return an error when it is cancelled or timeout (for the user interaction).
And it calls libusb_clear_hald which causes screwed up situation.

Sorry, I realized this myself this morning and did couple of fixes. rG7113263a00d8 does this all however I forgot to mention the bug number.

Argh. The following patch replaces the previous patch. It fixes the calculation of the display serial number.

I think the calculation of the OpenPGP s/n is not correct. As you write, "Yubico seems to use the decimalized version of their S/N as the OpenPGP card S/N." This matches my observation for my Yubikey:
s/n printed on Yubikey: 9074582
Yubikey s/n (with our prefix): FF020001008A7796
OpenPGP AID: D2760001240102010006090745820000

Great. Please apply the patch.

Okay, I now got such a patch:

I found a good enough solution: I changed the code to compute the OpenPGP s/n from the Yubikey s/n right after a Yubikey has been detected. Later, and if OpenPGP enabled on the YK, the S/N is already there but we use the S/N from the 0x4f DO. That is needed because we can't compute the OpenPGP version number ahead and use 0.0 in the S/N.

Please use shorter password.
For gpgsm, maximum is 31 chars.

Removing 2.2 tag because it has been fixed in one of the last releases.

Its done for 2.2 thus changing the tag.

How about distinguishing CARDNO and application specific SERIALNO?

A fix has been released; see T5052.

BTW, the idea is to fade out support for gpg --card-status and --card-edit. Thus no new features there. New features shall only go into gpg-card.

Fixing --card-status is definitely a good idea. gpg-card shows almost the same information as gpg --card-status except that it shows the correct "Version" and "Serial number". It would probably make sense to unify the code of --card-status and gpg-card's list command.

Let me describe current situation.

I just noticed that gpg --card-status now prints a bogus OpenPGP version number for my Yubikey. And it prints an empty serial number.

# gpg --card-status
Reader ...........: 1050:0407:X:0
Application ID ...: FF020001008A7796
Application type .: OpenPGP
Version ..........: 77.96
Manufacturer .....: Yubico
Serial number ....:

"Revoke Certification(s)" is available in

• Certifications Overview as context menu option for the user IDs
• Certifications Overview as context menu option for the signatures
• Certificate Details as context menu option for the user IDs
• Certificate Overview (aka key list) as context menu option for keys
• Certificate Overview (aka key list) as menu entry of Certificates menu

For 2.2, rG61aea64b3c17: scd: Fix the use case of verify_chv2 by CHECKPIN. fixed this problem.

It's fixed in master by T3465: --pinentry-mode loopback with --delete-secret-keys, with new confirmation interaction.
For 2.2, you can use --batch and --yes, see T4667: "gpg: deleting secret key failed: No pinentry" when in --batch mode with --pinentry=loopback.

Note: menu_backsign can be enhanced to detect such a case in the same way it detects missing backsigs.

We should find a way to figure out the OpenPGP S/N even if OpenPGP is disabled. I'll ask Yubico.

There is another problem: Even if the first certification was revoked, trying to add a new certification with --quick-sign-key fails because '"user id" was already signed by key ...'

I have tested this with Kleopatra. The good news is that SCD GETATTR $DISPSERIALNO now works for the piv app even if the openpgp app is enabled.

Unfortunately this new release has a regression affecting users with non-ascii account names. See T5098.

I am already working on it. The gpg command will be

I missed this one because I only searched for "revoke" ;-)

Seems to be a duplicate of T4095

Only enabled for UNIX #ifdef/#else/#endif

I had overlooked this fix rG044379772fc5: common: Fix the previous commit., after the commit of rGb1c56cf9e2bb: common: Use gnupg_spawn_process_fd to invoke gpg-agent/dirmngr..

Hello,
I finished the Italian translation of the GnuPg 2.2 file.
I need help, can you please update the source project with this translation? I am a beginner, unable to do this.
I attach files translated into Italian

I'm testing:

diff --git a/agent/findkey.c b/agent/findkey.c
index fa9e5b548..eec85ba67 100644
--- a/agent/findkey.c
+++ b/agent/findkey.c
@@ -996,7 +996,10 @@ agent_key_from_file (ctrl_t ctrl, const char *cache_nonce,
   if (r_passphrase)
     *r_passphrase = NULL;

We understand the problem, it's a regression from August. For T4083 we changed an internal function to better work with Windows UTF-16 filenames in preperation to at some point fully support UTF-16 and only use the wide character functions as system calls.
But that broke places where internally the local 8 bit encoding was still used.

I can reproduce this.

Observation:
The umlaut is displayed incorrectly on the command line (cmd.app) when the keybox file is created.
(This may or may not be relevant.)

Should not be too complicated.

Part of the task is the plumbing for that in GPGME of course, I'm not sure if werner will do the core "C" part directly or if you could do this also. But first let's get it added to GnuPG.

With 2.3 we add the keyboxd which uses sqlite (and thus indices) as database. This makes lookups much much faster and avoids problems with several processes accessing the pubring.kbx. If you want to try this you can do so with 2.3:

It should be possible to apply the patch rG7de9ed521e516879a72ec6ff6400aed4bdce5920
for 2.2 also to older 2.1 or 2.2 versions,

That keeps the group permissions of an existing directory. Needs to be backported to 2.2

The fix we have there has the problem that it forcefully changes the permissions. Consider the case that for example that group access was provided which will currently be reset with each start of gpg-agent.

--locate-external-keys exists since 2.2.17 and ignores the local keys.

See
https://lists.wald.intevation.org/pipermail/gpg4win-announce/2020-September/000089.html
for the fixed Gpg4win 3.1.13