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

FWIW, here an example of warnings we use. Yes it starts with -Wall but there are a couple of more specific warnings and at a few places we even use pragmas to disable warnings. And it depends on the compiler version used.

-Wall is not a good idea in general because it is too unspecific. This is why we have a list of useful warning and >warnings we ignore with gcc.

-Wall is not a good idea in general because it is too unspecific. This is why we have a list of useful warning and warnings we ignore with gcc.

I found the bug by compiling the package with C/C++ compiler clang and flag -Wall.

Fixed in gnupg and gpgme. it is not serious because that is just a failsafe check; libksba creates these strings and it does it correctly.

We have the same flaw in gnupg.

I mean:

diff --git a/common/utf8conv.c b/common/utf8conv.c
index 7804dbfcd..bdab225a9 100644
--- a/common/utf8conv.c
+++ b/common/utf8conv.c
@@ -138,7 +138,7 @@ handle_iconv_error (const char *to, const char *from, int use_fallback)
          native encoding.  Nowadays this seems to be the best bet in
          case of errors from iconv or nl_langinfo.  */
       active_charset_name = "utf-8";
-      no_translation = 0;
+      no_translation = 1;
       use_iconv = 0;
     }
 }

[These damned typos in commit messages ;-)]

It's pretty minor bug, it only matters for some strange scenario on Windows like:
(1) a user runs gpg --card-edit or gpg-card and keeps the user interaction for some reason (say, forgetting the terminal interaction), which keeps the pipe connection from gpg-agent to scdaemon
(2) While the pipe connection is used by the user interaction above, from another terminal, the user invokes gpg (say, gpg --decrypt) which uses socket connection from gpg-agent to scdaemon

I mean these uses of close:

diff --git a/scd/scdaemon.c b/scd/scdaemon.c
index b7bbc0361..a6925eaf9 100644
--- a/scd/scdaemon.c
+++ b/scd/scdaemon.c
@@ -797,8 +797,8 @@ main (int argc, char **argv )
       /* We run handle_connection to wait for the shutdown signal and
          to run the ticker stuff.  */
       handle_connections (fd);
-      if (fd != -1)
-        close (fd);
+      if (fd != GNUPG_INVALID_FD)
+        assuan_sock_close (fd);
     }
   else if (!is_daemon)
     {
@@ -932,7 +932,7 @@ main (int argc, char **argv )

if a user decided to use the Web Key Directory, this should be used instead of falling back to whatever has been configured (nothing else by default)

On the ml there was another request for this use case

I's say we should not do anything but solve that along with the move of all fd/fp/sock/HANDLE stuff to gpgrt to solve this at one place. We need that anyway to properly support Windows64. We won't be abale to do this for 2.3, though.

Fixed.

Taking: Still does not work although now --quick-set-expire is used by gpgme.

OpenPGP (RFC-4880) requires support for 3DES and SHA-1 thus you can't disable them. However, they are not used in practice because the key preference guarantee the use of more modern algorithms,

No more info was provided.

Pushed modified patch to master and 2.2.

That patch fixes the build problem I got into today when trying to build 2.3 for windows. So ? from me and please commit the patch as it is already required when assuan and gpgrt config no longer emit ws2_32 in their pgk-config --libs line.

Linking $(NETLIB) is required when the executable uses WSAStartup.

I just learned that WSAStartup can be called multiple times. So, it doesn't cause any erroneous behavior which I had been afraid of.

Thanks for looking into this. However, I do not understand the problem behind it. Is it the need to link against the socket lib? 10 or 15 years ago things were more complicated because two TCP stacks were in use and you could use the modern one only if a certain service pack or Explorer version was installed. That might be the reasons for some of the peculiarities we have in the code.