Ok, my fault, I missed that in the beginning there was logging in the background which consumed gpg's error message.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Dec 23 2025
If no logging is running in the background (that's something that often trips me…) on consecutive runs:
with Gpg4win-5.0.0-beta476
Yes, Kleopatra quits again with the beta from yesterday:
Dec 22 2025
Fixed in gpg4win-5.0.0-beta476
Fixed by applying a patch to our version of MinGW. This affected all Qt programs build with Qt 6.10.
This has likely a similar cause as T1794
Observations (confirmation wanted):
- If no other gpgol-client Window is currently showing, the newly created window will show on top
- With the config window showing (but nothing else)
- clicking on reencrypt the first time will fail to bring the window to the front
- cancel it and click on reencrypt, again -> window comes to the front
- Similar observations when clicking on view/decrypt, reply, etc. for the first / second time.
- Hypothesis: Windows might become whitelisted depending on their title
Merged, manually (e63f7c1a62bd94594c0d7cd4326b94afc0e5fe71)
Should be doable your QStandardPath::GenericDataLocation . See also T7987
I have been able to reproduce this on linux with gnupg 2.5.14.
I had two users (named Alice and Bob in the example), each generating a key pair.
These are the steps:
- Both users have the "use-keyboxd" option in their common.conf (i could not reproduce the bug without this option)
Dec 21 2025
Dec 20 2025
Dec 19 2025
Dec 18 2025
Back to WIP because I had to fix a regression.
Well, I tested this again. I created a new key and saved a copy. The I updated the expiration date to 2035 and sent the key to the LDAP server. Then I deleted the updated key locally and imported the old copy. Thus I have now:
Yesterday I was able to reproduce it once. But despite more than a dozen more tries yesterday and this morning, I could not anymore replicate it. I tested on Unix and one oddity was that I forgot to kill the keyboxd for a clean new test and thus it could serve old keys despite that the pubring.db was already deleted (but the inode still open by keyboxd).
@timegrid I would not tag this ticket with LDAP, as it is not LDAP specific
State in Gpg4win-5.0.0-beta446 and vsd 3.3.4 is this:
So the message is "Update Failed" for keyserver and "not found" for WKD.
In light of that the ticket is this old, I'll leave it at that instead of discussing further improvements beyond this single phrase.
These would have to go in a new ticket.
