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)

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:

https://invent.kde.org/pim/kleopatra/-/merge_requests/428

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:

This is really weird behavior. It seems other secret keys in the keyring may also change to "undefined" validity when the certification is done with another key. And something about the key which is certified is important.
But it can also happen that it is enough to just import a secret key without certifying anything with it for it to be shown as "undefined" validity.

This task is obsolete as we do no longer use the Temp directory for encryption (I believe since vsd3.3.0/gpg4win 4.4.0). Instead the file is written directly to the target location with the ending ".part". It is renamed there after the encryption is completed.

If Kleopatra is started in standalone mode then it shuts down properly.

The aim of this ticket is to map the message in Kleo for the corresponding gpg case to the "Not found" error in gpgsm and thus show the other message instead.

With a Kleopatra built before the update of Qt/KF/gcc etc. (and which shuts down properly) I see the same three log messages.