I'm asked three times for the passphrase, but otherwise I can confirm this.

Possible root cause: The S/MIME details window seems to lack a parent.

I have introduced this hint exactly because it's impossible to describe the rules automatically.

These hints are taken from the help.txt file.

gpg-agent passes to pinentry a short and a long hint for the passphrase constraints (see constraints-hint-* in pinentry.texi). If these hints are set, then pinentry shows them even before the user has started to enter a passphrase. The error message can then simply be "Read the hint, stupid!". Just kidding, of course.

We could use single letters or icons (with proper tool tip and accessible name). I'm not sure mentioning the cert usage is that useful.

I found the following issues while testing with NVDA:

1. In the Certificate Details dialog NVDA does not read the labels associated to the key properties when a property gets focus, e.g. it reads the expiration date, but it does not read the label "Valid until".
2. In the Certify dialog the "Advanced" expander lacks a focus indicator.
3. In the Certify dialog the explicitly shown tool tips are not read.
4. In the Certify dialog the explicitly shown tool tips are immediately closed if the mouse pointer is over them or if the mouse is moved a short distance.
5. When a dialog is opened, then a label that has initial input focus lacks a focus indicator.

Fixed

I'm not sure I understand. If you don't want pinentries depending on libX11, then simply disable those pinentries with --disable-pinentry-qt5, etc. For Wayland it may make sense to allow disabling it.

At least, pinentry-qt offers this functionality since 1.2.0 (see T5517: Improvements for symmetric encryption).

Isn't this (mostly?) done? See T5517: Improvements for symmetric encryption.

pinentry 1.2.1 has been released today

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?

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.

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.

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

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.

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].

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"

Hmm. Good point. Always adding -L${libdir} makes the .pc files easier to relocate.

Your patch looks good, but please take a look at
https://dev.gnupg.org/source/gpgme/browse/master/doc/HACKING
for the correct process to contribute code (or documentation) to GPGME.

Why should gpgrt-config change the information read from the *.pc files?

Thanks. QGpgME should now also compile with strict C++11. And C++14'isms shouldn't happen again unnoticed.

The information should now be updated automatically. F5 still won't change anything if the data on the smart card didn't change, but pressing F5 to update information about locally stored keys shouldn't be necessary in the first place.

The Smartcards view is not updated because the data on the card hasn't changed. The update can be forced by removing and re-inserting the card.

With GnuPG master and Kleopatra master I'm making (slightly) different observations.

Thanks for the report! Should be fixed.

Thanks for reporting and testing my fixes.

Yeah. F5 only refreshes the smart cards. It doesn't refresh Kleopatra's key cache.

Yes, it's a problem in gpg. gpg asks for the expiration date of the subkey

[  277s] EditInteractor: 4 -> nextState( GET_LINE, keygen.valid ) -> 5

gpgme replies with an ISO date

[  277s] EditInteractor: action result "21000101T120000"

Then gpg asks again for the expiration date

[  277s] EditInteractor: 5 -> nextState( GET_LINE, keygen.valid ) -> 4294967295

which gpgme doesn't expect, so that gpgme return a "general error".

Thanks! It seems that we pass the correct expiration date to gpg:

EditInteractor: action result "21000101T120000"

So, it's maybe a problem in gpg now.

Hmm. Please run the test with

GPGMEPP_INTERACTOR_DEBUG=stderr GPGME_DEBUG=8 TESTS="initial.test t-addexistingsubkey final.test" make -e check-TESTS

in lang/qt/tests under the build folder to get (a lot of) debug output.

This patch breaks adding existing ECDH encryption subkeys to a key because now gpg tries to treat the encryption subkey as signing subkey. This can be reproduced with test t-addexistingsubkey in gpgme.

All issues have been addressed except:

• No accessible feedback when checking/unchecking user ID

This is caused by a bug in Qt which doesn't report the checkable state to AT-SPI.

It seems that the case $libdir = '${exec_prefix}/lib64' is not handled correctly, i.e. I get

prefix=/usr
exec_prefix=${prefix}
includedir=${prefix}/include
libdir=${exec_prefix}/lib64
[...]
Libs: -L${libdir} -lgpg-error

in gpg-error.pc.