The problem is that this is a just a band aid at best. The underlying problem that shows up in other places is not fixed. We should apply the band aid only if we say we don't fix the underlying problem.

Here is my attempt:

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 :-(

done: https://invent.kde.org/pim/kleopatra/-/merge_requests/285

It is reproducible bug even with master branch.

Either this has super high priority or we fix S/MIME keylistings in GnuPG. I will write a mail with details as that involves customer information.

V5 keys should now work as good as V4 keys in Kleopatra. For testing create a "Curve 448" key and then try a few things. Everything should just work because it works for gpg. Kleopatra doesn't really do anything special for V5 keys.

with gpg4win-Beta-50: "Rückstellcode" is shown correctly with an ü

with gpg4win-Beta-50: "Rückstellcode" is shown correctly with an ü

Done. I don't think this needs to be tested extensively because it's just some UI texts that now show the Key ID (with 16 hex chars) instead of the short Key ID (8 hex chars). And for files including key material we also use the Key ID (of primary key and/or subkey) now for the filenames, e.g. when exporting a public/secret key/subkey.

The change will also be included in VSD 3.3.

The version check can now be extended to 2.2.45 <= gpg < 2.3.0.

werner: Can you also backport listing of "default-new-key-adsk" with gpgconf so that Kleopatra can check whether a default ADSK is set?

Fixed. Ready for testing.

Backported for VSD 3.3.

The fix needs to be backported for VSD 3.3.

Backtrace:

#0  0x00007ffff6643d10 in QAbstractItemView::selectionModel() const () at /lib64/libQt6Widgets.so.6
#1  0x00000000006fe608 in Kleo::KeyListController::Private::updateActions(KActionCollection*)
    (this=0x7fffe4005540, collection=0xdd7ae0) at /home/ingo/dev/kde/kleopatra/src/view/keylistcontroller.cpp:1141
#2  0x00007ffff51da593 in  () at /lib64/libQt6Core.so.6
#3  0x00007ffff7ad2655 in Kleo::KeyCache::insert(std::vector<GpgME::Key, std::allocator<GpgME::Key> > const&)
    (this=<optimized out>, keys=<optimized out>) at /home/ingo/dev/kde/libkleo/src/models/keycache.cpp:1422
#4  0x00007ffff7ad3072 in Kleo::KeyCache::refresh(std::vector<GpgME::Key, std::allocator<GpgME::Key> > const&)
    (this=<optimized out>, keys=<optimized out>) at /home/ingo/dev/kde/libkleo/src/models/keycache.cpp:1255
#5  0x00007ffff7ad5968 in Kleo::KeyCache::RefreshKeysJob::Private::updateKeyCache() (this=0xc81ff0)
    at /home/ingo/dev/kde/libkleo/src/models/keycache.cpp:1566
[...]

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.

on gpg4win-Beta-50 things look much, much better.

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.

This is implemented; just missing the backport that is requested in T7302

Backported to 2.2

gpg4win-beta-50: There are no duplicate announcements of the entries in the result table of a keysearch with NVDA

ok, with gpg4win-Beta-50, a search result is only selected and highlighted if it is the only result.

I have a look at the log file of gpg-agent.log. I can see that six PKDECRYPT requests are handled simultaneously. I think that it's out of secure memory to decrypt the private key which results pinentry request.

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

For the "unknown recipients" there was the good suggestion to not show that line at all. As it has no additional information which is not included in the new explanation. I like that, but only in the case that there are no known recipients at all, as it would be confusing to list only e.g. one known recipients and then not mention the 5 unkown ones, IMHO.