Thanks for the report. To keep things easy the empty comment is now translated to "(none)".

Pushed {rC254b140}

Wow! That is a great idea. Thanks!

I have added a setting which can be used to block URLs with certain schemes.

This should now work for all settings in Kleopatra's configuration dialog.

This change adds support for the new "ldapserver" option of dirmngr.
The now deprecated "keyserver" option of gpgsm is still read, but
changes are always written to the new option (and the old option is
cleared). This change removes support for the ancient "LDAP Server"
pseudo-option which new versions of gpgconf no longer support.

@jukivili , thank you for your comment.

I planned to reply to your email on mailing-list, but I just have too little time.

I added --ldapserver to gpgsm because of confusion of what a keyserver is. Right now we see a problem only with this alias but it is a more general problem with aliases. My patch to master was a for public testing - let's discuss this on the phone.

The above change now also makes gpgconf from master ignore the keyserver option in gpgsm.conf.

$ gpgconf --version
gpgconf (GnuPG) 2.3.5-beta17

For what it's worth: I suggest to remove the ldapserver alias of gpgsm's keyserver option in GnuPG 2.2 and 2.3 again. It was added not too long ago (in June 2021) and it was added after the new dirmngr/ldapserver option was added. The alias is causing regressions and trouble with its only benefit (as far as I can see) being that dirmngr has an option of the same name for the same purpose.

For X.509 servers Kleopatra currently looks at gpgsm/keyserver with a fallback to dirmngr/LDAP Server. The gpgconf interface change

* tools/gpgconf-comp.c (known_options_gpgsm): Rename "keyserver" to
"ldapserver" and set level to invisible.

in rG0b4fdbd5f41e: gpgconf: Return --ldapserver and --keyserver from dirmngr. breaks configuration of X.509 servers with existing versions of Kleopatra. I suggest to revert this change to unbreak Kleopatra.

Thanks for report. Those powerpc vector implementations expect that compiler optimizations are enabled and here provided CFLAGS did not have '-Ox' parameter. This could be worked around by introducing -O2 always when building those files (confiugre.ac & cipher/Makefile.am change) or using 'optimize' attributes to required functions (cipher/*-ppc*.c change).

Turns out that the aliasing is a problem; if we allow keyserver as an alias for ldapserver in gpgsm.conf we are not able to get the value unless we add dedicated handling for this. Test in 2.3 but we will have the same problem the other way around in 2.2.

What does kleopatra use to get the list of ldap servers - gpgsm or dirmngr?

The problem comes from the way we handle an alias. That actually depends on the order the options are specified.

Thanks for debugging. Unfortunately I doubled your effort 'cause I didn't looked into the report anymore. (System test done with GPA ;-)

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.