I'll flag it for re-testing with the next version.

The (): is the result of Formatting::formatForComboBox(d->key()) which has just been changed to Formatting::formatForComboBox(target) to fix T6154: Kleopatra: Assert in CertifyCertificateCommand after setting ownertrust of key. I think this issue here is just another symptom of the same bug as in T6154: Kleopatra: Assert in CertifyCertificateCommand after setting ownertrust of key. You were just quick enough to avoid the assert.

Looks like this option has been merged 16 years ago from gpg 1.4.3. My guess is that it was never used in gpg 2.x.

For the original issue I'd prefer to silence the error/warning with -Wno-narrowing because I think it's a non-issue. Or does changing the enum declarations to enum : unsigned int make clang happy?

If you use an IP address there is no server name and thus a) TLS can't check the name and b) virtual servers won't work. But as you stated this is not the problem: With rGb231959728a0056 (T2924) https is handled in another way than hkps.
Now, that change was only applied to KS_GET and not to KS_SEARCH. This is kind of correct but shows this surprising behaviour: For the preferred keyserver we really want to do a plain fetch and don't have all the hkp ip/name mapping we do.

For gpgme (as for the other GnuPG libraries) we use the good old mailing list based process for contributing patches. See doc/HACKING for details. In particular, we'll need a signed DCO from you.

Should be fixed.

also, in the recipient tab the "encrypt with passphrase" option is at the very bottom and so far away from the other options that it is easily overlooked, if the window is fullsized.

Turns out the error happened because on Windows I tested with the IP address and not the name. With gpg-connect-agent --dirmngr I get:

Oh, more testing shows that this works on Linux. strange.

Doing the same thing on my second PC, I can be more precise:

The delays are due to /usr/sbin/laptop_mode from the laptop-mode-tools package.

Inserting as well as removal is detected on my machine always only after 25 seconds

Right, this is only for the OPENPGP cards. Meanwhile we have
a way to get information on the supported algorithms. For example:

Yes, this is with Clang. I am working on getting it to compile on Windows with clang-cl, using vcpkg, with success. I have several patches to fix the issues that clang detected, and so I wonder if I should create a Task to discuss them all?

This (old) task only concerns OpenPGP smart cards resp. the OpenPGP card app, right? Because for PIV ECC has always been offered since PIV is supported. And for other card apps we do not even support generating keys AFAIK.

I'll reopen this ticket here, since the underlying issue is not quite resolved yet as @dkg helpfully outlined above.

scdaemon should return this information together with other information about the smart card or the key slot.

@werner please write a list for which manufacturer and version kleopatra should offer which curves.

g++: error: unrecognized command-line option '-Wc++11-narrowing'; did you mean '-Wno-narrowing'?

How did you get this error? I don't even see a warning for this when building gpgme with g++ (SUSE Linux) 12.1.1 20220812.

I wrote a simple testusb.c if monitoring USB devices works:

#include <stdlib.h>
#include <libusb.h>
#include <poll.h>
#include <stdio.h>

Thank you dkg. I am new to 'certificates' generally - and a little knowledge is a dangerous thing - but this is what I did:

@mpilgrem: in the meantime, for connecting to keys.openpgp.org, which *has* cleaned up its certificate chain, you might also want to try killing your dirmngr process, and/or cleaning up the data in .gnupg/dirmngr-cache.d/.

Basically, the website in question (e.g. https://openpgpkey.gnupg.org/, which exhibits this problem) serves up three certificates:

In T6136#161943, @ikloecker wrote:

This looks like a good approach, but I think stripping the standard paths needs to be deferred until later, because, if PKG_CONFIG_SYSROOT_DIR is set, then the library search paths are prefixed with $PKG_CONFIG_SYSROOT_DIR, and then the prefixed standard paths probably shouldn't be stripped.

Sure. I think we can do this after 3.1.24. I don't want to have additional string changes now as we have translation at 100%

Fix issues found while testing with NVDA.

For better usability and accessibility the [Yes] [No] buttons should be something like [Trust Owner] [Don't Trust Owner] resp. [Yes, This is My Key] [No, That's Not My Key].

I went back to 2.3.3 and it seems it never worked as I expected. But we should understand the reason for the long delay.

I am fine with that. No need for the WoT bells and whistles

Okay, the mentioned patch does not help. I now tried the actual use
case of mine, which is to ssh without the token plugged in. I clicked
two times OK, then inserted the token and then I had to click
around dozen times onto OK before the inserted card was detected.

I have had some problems detecting dark mode on Windows. Qt has a command line switch darkmode=1 or darkmode=2 for the windows platform theme. Which does not help. It also checks in QWindowsTheme for dark mode in the following code:

The interesting thing is that I did not changed my box but it "suddenly" started to misbehave. Thus I conclude this is a matter of our own changes. The log I sent you by PM was done with my suggested improvement (npth_unlock/lock around libusb_get-device_list) and it might actually helped a bit - I am not sure. I will test again w/o that change. Or maybe I should bisect.

What I learned today:

• libusb backend for Linux does:
  • scanning devices, it uses hotplug feature
  • hotplug feature uses udev_monitor_new_from_netlink and udev_monitor_receive_device, which are available in libudev (it communicates udev through AF_NETLINK socket)
  • libudev differs in Devuan
    • Distributions with systemd, libudev nowadays includes static-libsystemd
    • In Devuan, it is included in eudev : https://git.devuan.org/devuan/eudev
  • At initialization, hotplug feature spawns linux_udev_event_thread_main (its name is {libusb_event})
    • It is this thread, which receives information of device insertion/removal

Thank you for your work on the proposal. I have two comments:

• Do we have some test vector, which can be used in the testsute to test the new API?
• We need to mention the new API in the documentation.

I tried with no success.

Original pkg-config supports PKG_CONFIG_SYSTEM_LIBRARY_PATH (default is determined by build time, and overridden by environment var), PKG_CONFIG_SYSTEM_INCLUDE_PATH as well.

In T6136#161915, @orbea wrote:

Or maybe it would be better to only check the standard libdir paths as in the libgpg-error configure.ac?

--- gpgrt-config.orig	2022-08-21 23:14:40.017298485 -0700
+++ gpgrt-config	2022-08-22 08:28:16.339977281 -0700
@@ -210,6 +210,7 @@
     # the resulted list is in reverse order
     for __arg; do
 	case "$__arg" in
+	    -L/usr/lib|-L/usr/lib64|-L/lib|-L/lib64) ;;
 	    -l*)
 		# As-is
 		__rev_list="$__arg${__rev_list:+ }$__rev_list"