This is caused by a bug in gpgsm. The card serial numbers are missing in the with-colon key listing.

That's my mistake with KEM API.

Alright, I change it from for notation data (and name).

[GNUPG:] NOTATION_NAME foo@foo.org
[GNUPG:] NOTATION_FLAGS 0 1
[GNUPG:] NOTATION_DATA bla%20bla%20��%20blub

with change:

[GNUPG:] NOTATION_NAME foo@foo.org
[GNUPG:] NOTATION_FLAGS 0 1
[GNUPG:] NOTATION_DATA bla%20bla%20%81%82%20blub

Since rfc2440 the PGP specs say:

Here is a patch (revised since the email of mine):

For t-stringhelp.c, here is a fix.

For

openpgp_oid_from_str has a wrong memory-safety assumption

For Integer Overflow in literals_seen, I think that the claim is wrong.
When literals_seen becomes two, GnuPG stops processing to return an error.
It's not possible for GnuPG to keep processing.

For Integer Truncation of Arguments report, since the int value is limited to one-octet value, we could add check for the length of input when we use strtol.

We have fixed it but the commit also states:

I agree because the original purpose from the 90ies to enable the use of signed patch files in the Linux kernel community was never actually used and GnuPG stopped the distribution of patches from version to version many years ago. Thus I agree we should hide this option behind a compatibility flag.

Added a compatibility flag in: rGad0c6c33c3d6: gpg: Do not use a default when asking for another output filename.

Fixed in rG115d138ba599: gpg: Fix possible memory corruption in the armor parser.

Fixed in rGdb9705ef594d: gpg: Avoid potential downgrade to SHA1 in 3rd party key signatures.

Fixed in rG8abc320f2a75: gpg: Error out on unverified output for non-detached signatures.

This feature should be only enabled with a compatibility flag.

Mitigation would be: adding context validation in add_onepass_sig function, which checks WHAT of armored input.

That's a good question. Looking at https://datatracker.ietf.org/doc/draft-koch-librepgp/, it doesn't really specify what encoding is used for "human-readable" notation, so I'd personally lean towards encoding it to stay on the safe side. Unless I'm mistaken, status-fd will only be used locally, so escaping overhead should not be a problem.

The question is who shall correct the wrong encoding of notation data (assuming it is flagged as human readable). Escaping is a solution but needs a lot of extra bytes.

It is not an ADSK issue. The problem is that the new subkey has not been entered into the fingerprint table and can thus not be found.

That's what gpg-card url --clear does

if (!strcmp (argstr, "--clear"))
  url = xstrdup (" "); /* No real way to clear; set to space instead. */

Fixed in 2.5.13.

So we need to find out what gpg-card url --clear does to avoid the card error for the ZeitControl cards.

In gpg4win-4.4.1 it works too.

Note: In the current vsd beta (29) it works (pinentry for the next key is opened):

@werner Proposed patch for gpg:

diff --git a/g10/export.c b/g10/export.c
index 5dcb9c665..908a6b6a0 100644
--- a/g10/export.c
+++ b/g10/export.c
@@ -1961,7 +1961,9 @@ do_export_one_keyblock (ctrl_t ctrl, kbnode_t keyblock, u32 *keyid,
           if (strchr (hexgrip, ','))
             {
               log_error ("exporting a secret dual key is not yet supported\n");
-              return gpg_error (GPG_ERR_NOT_IMPLEMENTED);
+              err = gpg_error (GPG_ERR_NOT_IMPLEMENTED);
+              write_status_error ("export_keys.secret", err);
+              return err;
             }

Note: It works with gpg-card url --clear.

I could reproduce this with a ZeitControl OpenPGP v3.4 card, but (as Tobias) not with an (old) Yubikey. Looks like a bug in the card firmware.

This issue should be fixed in 2.6, too.

Pushed the change to gnupg master: rG61ff3759e827: common,dirmngr:w32: Fix for semi-hosted environment.

In libgpg-error, I pushed thread-safe version : rE0313b660f8bd: w32: Don't convert slash->backslash when it's under Wine.
I'm going to push similar code to gnupg master.

For completeness, that's https://gitlab.freedesktop.org/poppler/poppler/-/issues/1595. dkg obviously filed that but it may be useful for others finding themselves here.

I'm fixing this issue under T7855. So, I move this ticket as a child of T7855.

@timegrid Thank you for your confirmation.

I can't reproduce this in vsd-3.3.90.19 @ win10 anymore.
Probably the fixes in https://dev.gnupg.org/T7827 or https://dev.gnupg.org/T7855 solved this, too.

The problem here is that iobuf_readbyte returns -1 on error and on EOF. parse_packet is not able to distinguish that because for histroic reasons we do not return a gpg-error code (GPG_ERR_EOF). To fix this we need to change all callers of parse_packet to not act upon -1 but only on an error code.

I updated the branch.

Since GnuPG 2.5.3 there is no predefined keyserver anymore: https://dev.gnupg.org/T7442

For the full fledged Windows installer see https://files.gpg4win.org/Beta/gpg4win-5.0.0-beta369/gpg4win-5.0.0-beta369.exe

Is that really the same bug? I would be interested in seeing a more detailed report. BTW, Windows or Linux? Used standard beta installer on Windows?

Especially when an LDAP is configured, keys should be automatically refreshed in short intervals (5 days? Configurable?) to notify users about revoked keys or signatures from a trusted key.
Keys that are close to their expiration dates should be prioritized.
Maybe users want to configure for what mail domains a lookup on a configured LDAP should be done.

You may also specify a mail address in which case gpg tries to find the best matching key. For example the latest key with that mail address. See gnupg/g10/getkey.c:get_best_pubkey_byname

Nope: There are many different error codes returned, Kleopatra may want to map them to a common one.

We need a better error code from gpg to change this

Pushed the changes in {gniibe/synch-spawn} branch.
It consists of three commits:

• rGb8b8afc5cf6f: build: Require libgpg-error 1.56 or newer.
• rG15b8bc7495db: w32: Synchronous spawning gpg-agent/dirmngr/keyboxd.
• rG6bd6826aa6ff: common:w32: Care about the NUL device for start_new_service.