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

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.

Note that 2.5.11 fixes a regression in 2.5.10 regarding the use of notations for 3rd party signatures. See T7743

I can confirm that the crash is fixed by the change.

Urgs

Fixed for gnupg22 and gnupg26

This does not happen with gnupg24 because the cache has not been implemented there.

Thanks. Will go into 2.4.9 to be released soon.

I'm testing the following patch with experimental change of libgpg-error.

We already have an initialization function in gpgrt which is thread-safe at least if used as a DLL. Maybe move the check to there.

In libgpg-error, we have: rE65114f24e13f: w32: More changes to the extended length path handling.