It seems we were still providing the expired DST certificate, which led to an additional yet invalid trust path, which gnupg didn't consider "valid" overall. Mainstream TLS implementations are more lenient here which masked the issue for a bit.

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"

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

This was apparently discussed before:
https://www.mail-archive.com/ports@openbsd.org/msg105601.html

Also in:

I tested with a self-signed one.

I suggest simply removing any -L linker path from the output if it matches the $libdir in gpgrt-config.

Did you test with a self-signed cert? I ran into the problem that the selection only showed the root certificate, the signing works using the leaf cert, but the root cert was put into the signature. Changing Scute to only return the leaf certificate made it work but verification failed.

I can successfully sign with LibreOffice Writer (using Brainpool with Yubikey). I need to do:

• Tools
  • Optoins
    • LibreOffice - Security - Certificate Path
      • Select the profile of "firefox:default-esr" for NSS certificate directory

Even without libassuan-config installed in libassuan-2.5.5.

$ gpgrt-config --libdir=/usr/lib64 libassuan --libs
-L/usr/lib64 -lassuan

gpg-error is not affected at least.

 gpgrt-config --libdir=/usr/lib64 gpg-error --libs
-lgpg-error

In lang/qt/tests/Makefile:

LIBASSUAN_CONFIG = /usr/bin/gpgrt-config --libdir=/usr/lib64 libassuan
LIBASSUAN_LIBS = -L/usr/lib64 -lassuan

gpg-error-config and its relatives (libassuan-config, included) were written before pkg-config. The support of cross build, multiarch, and multilib by those are quite limited (and sometimes wrong). Basically, those scripts are deprecated, but it has been kept for backward compatibility.

It seems the issue is also in libassuan-config.

$ libassuan-config --libs
-L/usr/lib64 -lassuan -lgpg-error

The shell logic here does not seem quite right to me.

what's new for a possible gnupg 2.3.8 or gpg4win 4.0.4 release?

what's new for a possible gnupg 2.3.8 or gpg4win 4.0.4 release?

I imported the public key using Kleopatra.

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.

Probably, PIPE_REJECT_REMOTE_CLIENTS mode and lpSecurityAttributes=NULL is OK.

Our tests are fine as of rM2e7a61b898fc.

Yes, that patch is not a great solution. Ideally there would be an interactive choice in the gpg CLI between encrypting/signing subkey during the add-existing-subkey operation.

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

It will be a lot of work to change this in gpg. Thus ISO dates were only introduced with gpgsm after the former glibc maintainer refused to switch to a 64 bit time_t - which would have been easy enough at that time (about the year 2001).

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

For the record, the changeset in the attached merge request is final and waiting for reviews.

Experimental branches:
https://dev.gnupg.org/source/libgcrypt/history/t4873/
https://dev.gnupg.org/source/ntbtls/history/t4873/

Thank you for your log.

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.

WIP with those three patches:

Yes, I removed them accidentally because they were listed under the keyserver option heading in gpg. They actually belong below the import/export heading.

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.

I am attaching the files. The "gpgconf --list-config" gave the error "gpgconf: can't open global config file 'C:\\ProgramData\\GNU\\etc\\gnupg\\gpgconf.conf': No such file or directory", so I tried the "gpgconf --show-configs".

ACS readers simply don't work reliable under Linux.