Without the above patch the ARGPARSE_ATTR_IGNORE, ARGPARSE_ATTR_FORCE, and ARGPARSE_OPT_IGNORE flags in arg->r_type are never set for a not-ignored option with argument.

The following experimental patch (which may be complete non-sense and/or may have undesired side effects) seems to fix it

diff --git a/src/argparse.c b/src/argparse.c
index a144881..7cd8ba7 100644
--- a/src/argparse.c
+++ b/src/argparse.c
@@ -1874,6 +1874,7 @@ _gpgrt_argparse (estream_t fp, gpgrt_argparse_t *arg, gpgrt_opt_t *opts_orig)
                         xfree (buffer);
                       else
                         gpgrt_annotate_leaked_object (buffer);
+                      prepare_arg_return (arg, opts, idx, 0, 1);
                     }
                 }
               goto leave;

I think in the block below

else if (state == Acopyarg)

there is a prepare_arg_return missing.

I think the no change flag is wrong for all options that have arguments.

Tip: Use -v to get a human readable list of flags.

Doh! gpgme already performs the unescaping of data retrieved via the Assuan protocol for us in llass_status_handler. Doing it again in Kleo::SCDaemon::getReaders was simply wrong.

For the record, there is a new report on the mailing list about this module on MacOS:

There are reasons why we don't used pcsc-shared by default; for example: Not all OpenPGP cards support reading the current verification state (whether a PIN has already been entered) and thus we use a local cache for this. Other shared applications may change the state behind our back or even switch to another application on the card. Thus we use the safe way.

Hmm, I looked at the gpg-side a bit. assuan_send_data that's used for returning GETINFO reader_list only does escaping "as required by the Assuan protocol", i.e. percent escaping of certain characters but no plus escaping.

Thank you, applied both of two patches.

Thanks, fixed.

Yes, kleo always maps '+' -> ' '

Thanks. Looks good to me.

DANE has been an experimental thing and is imho dead.

Implemented extended headers for filenames and linknames (on Unix).

Thanks for report. I got similar report earlier this week from gentoo user through email and made following patch for them to test. I'll push it to master soon.

Sorry about that! Maybe consider adding a line "Check that the issue persists in the latest version" to the "How to file a bug". I was going through this list, so it would have caught me.

This looks like a missing escaping issue in the sender (scdaemon?) or an unwanted unescaping issue in the receiver of the string (which uses Kleo::hexdecode()).

Thanks

gpgme_key_t is a different kind of object than a gpgme_foo_result_t and thus has different properties.

Please try again with a recent version of GnuPG (2.2.33 or 2.3.4) and libksba (1.6.0) and reopen this bug if the problem persists.

The bug with the long filenames has been fixed but it is not yet released. Release will be in gpg4win 4.0.1 See T5754.