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.

Another problem seems to be that libtool/automake does not differentiate between library dependencies needed for building the library itself and library dependencies that should be exported to users of the library. There's just mylib_la_LIBADD for specifying the internal/private library dependencies and those also end up as dependencies in the .la file. Or maybe the dependencies in the .la file are used by the original libtool only for building static libraries and it's slibtool's fault to also copy the dependencies verbatim when building a shared library.

I have checked where -L/usr/lib64 comes from. Ultimately, it seems to come from gpg-error-config --libs which outputs -L/usr/lib64 -lgpg-error. I have no idea why gpg-error-config --libs adds the -L/usr/lib64, but this seems very dangerous to me and was bound to cause trouble because a -L applies to everything that follows and not just to the following -l.

You probably have to call strace with -f, so that processes started by clang are also straced.

Your observations seem to confirm that the linking picks up the old 1.17.1 version of libqgpgme instead of the newly built one. You could use strace to dispel last doubts. In any case this very much looks like a problem in slibtool.

Hmm. There is a -L/usr/lib64 before -L../src/.libs. I guess this causes problems if there is a /usr/lib64/libqgpgme.la because this will be found before the newly built libqgpgme.la in the build directory.

revokekeyjob.moc is included by job.cpp (as many other *job.moc files). The missing symbols should be available in the built libqgpgme.so. The command line

rdlibtool: link: clang++ t-revokekey.o t-support.o -g -O2 -L../../cpp/src/.libs -lgpgmepp -L../../cpp/src/../../../src/.libs -lgpgme -L/usr/lib64 -lassuan -lgpg-error -lassuan -L../src/.libs -lqgpgme -L../src/../../cpp/src/.libs -lgpgmepp -L../src/../../cpp/src/../../../src/.libs -lgpgme -lassuan -lgpg-error -L../src/../../../src/.libs -lQt5Core -L../../../src/.libs -lgpgme -lassuan -lgpg-error -lQt5Test -lQt5Core -lstdc++ -o .libs/t-revokekey

includes -L../src/.libs -lqgpgme. So it should link against the newly built library and not against an installed library.

I have no idea why OpenKeyChain cannot decrypt TestFileB.pdf.gpg. Here is the packet list (with automatic decryption).

$ gpg --list-packets TestFileB.pdf.gpg
gpg: encrypted with rsa3072 key, ID B29C3E00B6EF27FA, created 2022-08-12
      "TestKey4 <TestKey4@Email>"
# off=0 ctb=85 tag=1 hlen=3 plen=396
:pubkey enc packet: version 3, algo 1, keyid B29C3E00B6EF27FA
        data: [3071 bits]
# off=399 ctb=d2 tag=18 hlen=2 plen=0 partial new-ctb
:encrypted data packet:
        length: unknown
        mdc_method: 2
# off=420 ctb=a3 tag=8 hlen=1 plen=0 indeterminate
:compressed packet: algo=1
# off=422 ctb=90 tag=4 hlen=2 plen=13
:onepass_sig packet: keyid BBF1585AFE6385A9
        version 3, sigclass 0x00, digest 10, pubkey 1, last=1
# off=437 ctb=cb tag=11 hlen=2 plen=0 partial new-ctb
:literal data packet:
        mode b (62), created 1660319025, name="",
        raw data: unknown length

$ gpg --list-packets TestFileA.pdf.gpg 
gpg: encrypted with ECDH key, ID 8594A0FBC4AFAF88
gpg: public key decryption failed: No secret key
gpg: decryption failed: No secret key
# off=0 ctb=84 tag=1 hlen=2 plen=94
:pubkey enc packet: version 3, algo 18, keyid 8594A0FBC4AFAF88
        data: [263 bits]
        data: [392 bits]
# off=96 ctb=d4 tag=20 hlen=2 plen=0 partial new-ctb
:aead encrypted packet: cipher=9 aead=2 cb=16
        length: unknown

-> This still uses AEAD. It seems Werner's method to remove the AEAD feature doesn't work. At least not with gpg 2.3.7.

$ gpg --edit-key 8594A0FBC4AFAF88
Secret key is available.

Does the progress bar really say "Verschlusseln" (with u instead of ü) or this is a bug in the screen capture tool? In the pinentry dialog there are also two ü that are displayed as u.

Observations:

• TestKey1 (gpg 2.3) is an ECC-key (ed25519/cv25519) while TestKey3 (OpenKeyChain) is an RSA-key (rsa3072). I assume that OpenKeyChain supports ed25519/cv25519.
• TestKey1 (gpg 2.3) states that it supports some advanced OpenPGP features: features: 07 (= 0x04 + 0x02 + 0x01).
• TestKey3 (OpenKeyChain) states that it only supports one advanced OpenPGP feature: features: 01

Some details about TestKey3:

$ gpg --show-keys backup_2022-08-11.sec
pub   rsa3072/BBF1585AFE6385A9 2022-08-12 [SC]
      4AFA1B0808A82E3EF941B067BBF1585AFE6385A9
uid                            TestKey3 <TestKey3@Email>
sub   rsa3072/F3E9DFE37D777AEF 2022-08-12 [E]

Some details about TestKey1_0x31B038AA:

$ gpg --show-keys --verbose TestKey1_0x31B038AA_public.asc 
pub   ed25519/CD1E530031B038AA 2022-08-12 [SC] [expires: 2024-08-11]
      A438C95B6CAA724BC9F3DEB9CD1E530031B038AA
uid                            TestKey1 <TestKey1@Email>
sub   cv25519/B390B84B58866C6A 2022-08-12 [E] [expires: 2024-08-11]

Please don't yell at us!

All issues were "fixed" by getting rid of the dialog for T6115: Kleopatra: On "revoke certification" do not offer keys which did not certify that certificate.

Depending on what the user selected (key, one or more user IDs, a single certification) all certifications that the user can revoke are determined and, after confirmation, are revoked one after the other.

The option to flag a user ID as the primary user ID is now available in the Certificate Details dialog as button below the user ID table and as context menu entry of the user ID table.