A bit more verbose description would be helpful ...

Closing because POP3 is rarely used and has never been supported.

More than a year old - we can reduce the priority.

Note: The code for this is in the work/mmontkowski branch but has not yet been merged with master. Before we take this bug up again, we need to look closer at the ribbon UI events as remarked by Andre on July 29.

That was resolved with vsd 3.2.0

The Libgcrypt version you are using has not been build from git or a released tarballs. Only with a released tarball you would get no suffix. With git bou will see a -betaNNNN suffix.

Backported to 2.2

I don't think it makes sense to add such a feature/bug fix to the old versions.

We won't do that for Windows.

Fixed in 2.2 with: rGc33523a0132e047032c4d65f9dedec0297bfbef3

Yes, this is a bit annoying but recall that for v3 keys you can't even deduce the keyid from its fingerprint.

I guess this is now fixed for all branches.

Oh. I should have noticed that. Thanks for fixing.

Please go ahead and apply to master. I'll take then care of backporting.

I would exclude them.

Okay, okay: s/private key/secret key/

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

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

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

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.

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.

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.

Actually we have similar problems with the 2.4 branch - in particular on Windows. We can quite easy reproduce this when using Kleopatra. Thus the working hypothesis is a locking problem because Kleopatra uses several threads and the order of actions recently changed.

See new subtask T7290 for smartcards and the link entries mentioned above.