Alright, we should do that in any case because two key caches are never a good idea and in particualr not if one of them needs too be reloaded too often. Thus re-using the one in Kleopatra is the proper solution. I recall that we looked at this at a time when we already started to design gpgol2 which would solve the problem anyway. However, at least for vsd we need to keep on using the classic gpgol for quite some more time. Thus the effort to improve the key resolving in gpgol is really justified.

Something which has high priority but has not been touch can't have a super high priority.

Please write at least a short description and give it a priority

Pretty brief description :-(

I see only links to our own pages and to the emailselfdefense - which is a good resource.

Hmm, two years old - I doubt that it makes sense to continue here.

Priority lowered in the light of the the forthcoming gpgol.js

Should definitely work with gpg4win if it works with vsd.

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.