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.

I applied rGb804378f183f: kbx: Fix a race condition on DATABASE_HD. in master. Let us see how behavior changes.

I found one problem. This problem may result lock-up on Windows, I suppose.

I mean: two gpg-agent requests simultaneously running DEVINFO --watch.
Single scdaemon, two threads handling DEVINFO --watch simultaneously, by pselect + read.
Two threads waken up, but it was only one thread which can read(2), another was blocked (before the fix).

Kleopatra does a full key listing after an import (triggered by the file system watcher noticing changes in GNUPGHOME). In general, Kleopatra always does full key listings.

You mean it is possible that the initialization function is called by several threads - or that two scdaemon's are running before they realize that one of them is in the way?

How does Kleo's key listing after an import work? Does it do a full listing or just updates the imported keys? Keep in mind that the import merely sets a flag in the trudtdb to be evaluated by the next key listing.

Status messages on successful creation of signed & encrypted archive

2024-09-18 15:21:33 gpgme[3250.d47]     _gpgme_io_read: check: [GNUPG:] PROGRESS gpgtar c 0 3<LF>
2024-09-18 15:21:33 gpgme[3250.d47]     _gpgme_io_read: check: [GNUPG:] PROGRESS gpgtar s 0 62 B<LF>

Tobias is working on this

I don't see how Kleopatra is responsible for updating the trustdb. As Andre correctly commented, Kleopatra sets "no-auto-check-trustdb" only for the initial key listing.

Setting to Testing and WiP to reflect status of the subtasks and to get it removed from the Open Tasks list.

This was implemented by Tobias

show no text "not VS-NfD compliant" for invalid signatures

For POSIX, I found an issue of T7151.
If you are using multiple clients which invoke SCD DEVINFO --watch, the problem should be fixed.
If it's not the case, let us locate a bug (or two).

Fixed in rGfc30f7059650: scd: Fix DEVINFO to allow multiple clients.

I realized that I put a bug on POSIX; When multiple clients do DEVINFO --watch, it is possible for scdaemon to hang (waiting pselect and read, read by one, read by another is blocked).