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.
Thu, Aug 18
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.
Thank you for your log.
Wed, Aug 17
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.
[ 274s] + pushd lang/qt/tests
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 ;-)
@ikloecker Thank you. You're right. Please go ahead.
Tue, Aug 16
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.
Mon, Aug 15
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
using this key file:
Panel Used By