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.

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