I'd write: "This means that the data you want to decrypt was not encrypted to any of your private keys."

The test with Gpg4win 4.3.1 (using GnuPG 2.4) seems to indicate that:

1. gpg didn't update the trustdb automatically after importing the extended trusted certificate.
2. gpg updated the trustdb automatically after deleting and re-importing the expired trusted certificate, but Kleopatra still showed the certificates signed by the trusted certificate as "certified". This could be a bug in the trustdb calculation (note the log message "Schlüssel C5D6C919005F36A4 ist als ultimativ vertrauenswürdig gekennzeichnet" which could indicate that gpg treats the key as valid although it's expired). On the other hand, my test with GnuPG 2.4 on Linux doesn't reproduce this problem.

Things look good on Windows. A quick test using gnupg24 with backported patches did not show any hangs. More testing will follow next week.

We will therefore have to form an idea of ​​the kind of person one must be, to be able to deliberately put oneself in a position of not being able to answer, by using a rather dubious pretext, insinuating the ignorance of a third audience about the inconsistency which, however, anyone could independently state. Thus, in this path you have chosen to persevere. Well then, you alone know the rules of your game.

And I can replicate it with the Appimage for VSD 3.2.2, too.

The issue is the same on import on the command line. So it's a gpg issue.

gpgme now checks for a SUCCESS status emitted by gpgtar when creating a signed and/or encrypted archive. If gpgtar is killed (or exits without emitting SUCCESS for some other reason) then the partially created archive is removed and Kleopatra reports a failure.

ok, the following is with Gpg4win 4.3.1.

@werner: I reproduced this before creating the ticket… With a VSD version and a Gpg4win Testversion. I'll add Audit Logs.

The change of spawn functions (basically, it was factored out to libgpg-error) results more possibilities to have blocked scdaemon, since the implementation in libgpg-error introduced context switch points when it spawns a child process.

Found another thinko; When there is no clients with DEVINFO --watch, the pipe to be notified is not consumed at all (no read). It eventually results blocked by write(2), when the pipe is filled.

The import code related to the trust management did not change since 2018. Thus I doubt it depends on the version.

I'm unable to reproduce the problem with Kleopatra master (Qt 6) and GnuPG 2.4.

I don’t think I have any other client that would invoke SCD DEVINFO --watch.

It's possible that the file system watcher does not yet support keyboxd. (Ideally, keyboxd would report changes via assuan to processes listening for changes. The file system watcher is obviously just a workaround.)

This fix has the problem that for a signed message where the signing key is not available gpg emits the decryption_failed status line and prints "WARNING: encrypted message has been manipulated". This is because we use log_error to show that the signature could not be verified due to a missing key. The extra check we introduced with rG50e81ad38d2b lloked at the error counter and thus triggered the decryptio failed.

Do you have scd-event script in your GNUPGHOME?

This still seems to be a problem. I was using Outlook 365 version 2408 and the current GpgOL and moving a signed email didn't work correctly. But there seems to be a difference when I move it by using the context menu or by using drag 'n' drop.

Does the file system watcher catch that keyboxd changes its database file below public-keys.d ?

I see. the systemd race of having two gpg-agent processes. The second gpg-agent should eventually go away but than it is already too late.

Sounds very reasonable. Maybe the initial idea was to open the database directly after keyboxd start and before and connections are accepted. My usual try to optimize a mutex away - I should not do this.