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.

There is a reason that we switched to ISO Date strings in large parts of GnuPG ;-)

Hello again,

@ikloecker Thank you. You're right. Please go ahead.

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.

Any progress on this?

This has been in the last releases.

Just tested this on Windows, works now as expected. Thanks.

Thinking about this, the best way to avoid AD code in Kleopatra would probably be to just create a QProcess that executes Powershell or WMIC to query the AD.

Here is an example

If the stub has been created or updated we will now ask for the card
with the Display-SN. If in addition a Label has been set to the key
that label is also shown. Note that the Display-S/N is associated wit
a card but the Label is associated with a key. For example if the
same key has been stored on two cards, the prompt will ask for one of
those cards but shows the same same Label. It is sufficient to insert
any of the cards with the key because that is what we actually need.

In master we already have Token lines which are created but not yet used. I am going to extend this with the display S/N and drop the idea of a separate Display-SN entry.

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.

Note that gpgrt-config supports the PKG_CONFIG_PATH and PKG_CONFIG_LIBDIR environment variables.

It's in 1.18.0.

It's in 1.18.0.

Please note that with newer libgpg-error releases, you can safely not install or can safely remove installed gpg-error-config. For GnuPG and its friends (including gpgme), gpgrt-config with gpg-error.pc are used instead (when no gpg-error-config).

Push the change.

gpg-error-config (which is old shell script to offer functionality of pkg-config) gives -L/usr/lib64 when it is configured at the build time.
gpg-error-config hasn't got improved, but kept its behavior (for backward compatibility and lesser surprise), while we are moving to the support of gpg-error.pc (by pkg-config and/or gpgrt-config).

Maybe the solution would be to stop using gpg-error-config and start using pkgconfig instead?

$ pkgconf --libs gpg-error
-lgpg-error