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.

Given that we backported it to gnupg22 we should go ahead and implement that flag. For example: if the flag is set for any root CA we will show compliance only if that flag is set for the specific root CA. This way we can introduce this feature w/o too much backward incompatibility. We could also hide the feature behind a compatibility flag. There is no reason why we should not add the de-vs trustlist flag to our vsd configuraion files, right away.

This has now been implemented for gnupg26 for public key encryption. However, symmetric key encryption, a man page, and the gpgme support are missing right now.

I'd vote for the second (utf-8) which is more aligned with our other APIs.

The environment is a property of the C runtime and well defined as a block of concatenated C-strings terminated by a zero length C-string. In case of wmain the C-strings use wchar_t and not char.