- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Mar 29 2024
I rebooted, edited the scdaemon.conf to match the above, and tried gpg --edit-card with the yubikey plugged in. It resulted in the same output:
Mar 28 2024
What does gpg -k / gpg -k --with-colons say?
yes, the box comes up, the second "user-level"-Kleopatra exits again after clicking the "ok" Button.
After quitting the Kleopatra process with the admin rights again the privileged background processes remain, like I mentioned in https://dev.gnupg.org/T7050#184583.
Yes, the kleopatra.exe process ist shut down for me with that version, too.
But I wonder if the remaining gpg-agent and scdaemon processes which remain may cause issues later on. The are still running with elevated rights according to the process explorer after restarting as normal user. It does not cause any immediately obvious issues, though.
No more additional dirmngr.exe processes come up in VS-Desktop-3.1.92.39-Beta, too.
Following your suggestion I have created T7067: Kleopatra: Add origin information in search results for the last open point
Note to self: The error message that nothing was found on the keyserver will still come up if one is configured. That will be fixed with T6493.
For the reference, for now i just did the dummy install in the Fedora spec file:
Please use
Tobias, if you find some time, can you please see how this can be done.
Trying to reach Ralph Seichter via the eMail address he is using failed – Osterferien?
The certificates from the same test smart card work in Version 3.2.2.231170 (Gpg4win-4.3.1), too, but there all certificates are shown, that is one more than in the VSD version. Seems gpg2.4 can handle certificates which 2.2 does not accept. But that is nothing to complain about.
Please keep also in mind that the OpenPGP card specification has always and is still developed along with GnuPG . Thus if there are any uncertainties in the specification GnuPG's way of handling thing is the way to go. If there is a way to chnage things without risking any breakage we can of course fix that. In all other cases we need to continue wit the current way. For larger changes in the spec we can of course cleanup stuff - Achim is currently reworking on a revision.
Thanks. I wonder if we should inform distros about this?
Please keep in mind, that it is not only about GnuPG and the OpenPGP card, but also between GnuPG and other PGP applications. I'm not really sure what the recent commit is doing, if it only affect the reading or also the writing of the data. But IMHO GnuPG should stick to the standard also if writing the KDF DO data because eventually, it will be used for authentication with the card.
Mar 27 2024
Fixed in 24.02.2
Sure WKD is still checked if the conditions for an update via WKD are fulfilled.
It's not a different kind of data. In both cases it's the serial number of the smart card either in human readable form (often as printed on the smart card/USB token) or in "untranslated" raw form. It's a bit like short Git hash vs. full Git hash.
what about the case that the key has a mail address? Is WKD still checked?
works for latest VSD Beta, too (VS-Desktop-3.1.92.39-Beta)
looking at my private key directory, the data for the display serial number seems to not always be there FWIW.
While reviewing the changes I had some doubt about some of the columns.
FYI as a VSD customer you have access to support. Please check Help-> about Kleopatra for the infos,
In a current version I see this at least if I do not quit Kleopatra completely and restart to another screen setting. Further testing at the moment is not warranted, as there will be changes to the columns handling with the switch to Qt6. (T6924)
Btw compare the Kleopatra versions in Gpg4win and your VSD Version. They should mostly be identical with VSD maybe lagging a bit behind, Or your emplayer has not updated VSD. Many don't
We're waiting for a RNP v0.17.1 release which intends to tolerate this mode.
https://github.com/rnpgp/rnp/issues/2198
https://github.com/rnpgp/rnp/pull/2190
This is fixed on RNPs side: https://github.com/rnpgp/rnp/issues/2198
After much investigation and debugging it turned out the problem really was that KOrganizer was hiding declined and unanswered invitations. Fixed already in master and 24.02.
Btw we should probably add TB in our QA environment to check for such things. Esp. with future changes in GnuPG we should try to use TB and maybe a bounycastle MUA (Greernshield?) to avoid creating accidental incompatibilities.
I cannot think of any of our products where you cannot chose the signing key.
From your description it is not clear what you did exactly.