Adding vsd33 for testing with next VSD

respecting the "disabled" state is ready for testing; the rest won't be done on this ticket

backported

should be ready for testing

backported

backported

backported for vsd33 to avoid conflicts with changes for T7076

backported

backported

The changes where backported for VSD33, but they have little to do with the original request. They only address https://dev.gnupg.org/T6072#167392

backported

Backported for VSD

Tested with Gpg4win-4.3.2-beta23: This works if I select the origin column for display. At least for WKD and keyserver.

Tested with Gpg4win-4.3.2-beta23:

Tested in Qt 5 build Gpg4win-4.3.2-beta23: Configuration dialog looks good.
Qt6 was tested by the developers

While I was about it, I also moved the compendium entry above the "More Documentation" entry.

Browsers automatically add an increasing number to the file names of downloaded files in case of a conflict. I think that's a strong indication that people don't like to be bothered with such things. But let's see if people complain.

works, tested with Gpg4win-4.3.2-beta23

works, tested with Gpg4win-4.3.2-beta23

Makes sense. Then default-new-key-adsk needs to be exported by gpgconf, so that gpgme/Kleopatra can use/show it.

Let us drop the option to select the ADSK and instead take them from the gpg.conf configured ADSK for new keys. Thus a simple dialog with a confirmation will be sufficient. We add some magic to gpgme to allow this with the adsk API. This solves the use-case to add ADSK to alread-existsing keys in the same way as they are added to new keys.

To add some (unrepresentative) statistics: My normal keyring contains 552 keys. 5 keys have a single revocation key. 1 key has 3 revocation keys.

What's the use case for multiple designated revokers?

What's the use case for multiple designated revokers? I don't think we should optimize Kleopatra's UI for something that's in theory possible with the OpenPGP spec, but which in practice will never occur for a productively used key. The standard use case is that the company wants to be able to revoke the keys of their employees, i.e. there will be a single revocation key.

Alternatively the revokers could be listed in a separate tab in the details dialog.

There could be several designated revokers, and it's a direct key signature.
So it's like a certification, but not linked to a user ID, but to the key.
Therefor it can't be stored in one field.

I don't think this UI makes much sense. From the user's perspective (and from the gpgme API), designated rekovers are not related to certifications at all. Shouldn't we rather just show this as a field in the list of metadata above the tabs in the certificate details dialog?

For OpenPGP cards >= v2.0 there is no PUK due to updated ISO standards but we use the term in Kleopatra for the Reset-Code.

Information about revocation keys can now be retrieved from a Key object (see T7118).

Information about revocation keys can now be retrieved from a Key object. Verified with internal test runners. Independent tests will be done with T7095.

I've moved the gpg task to a new ticket, T7133: Add feature to load designated revoker from LDAP
The Kleopatra task is obsolete, as it was noticed that the proposed option is already in gpg and should not be implemented twice.

I think it would be cleaner to create a separate ticket for making gpg fetch the requested key from LDAP.

Although it is implemented in gnupg-2.2 we should add another feature: Iff this option is configured, gpg shall try to load the requested key from LDAP in the same manner as it does for a trusted-key.

this has been implemented since february 2023 in all gnupg versions

Assigning to Carl since he's working on this already.

Setting same priority as T6799.

We shouldn't change the name of the config file. The syntax is different from GnuPG's .conf files. Therefore it's better not to use the same file suffix.

I'm re-opening this ticket because I think this ticket only partially overlaps with T6799. T6799 is specific for g10 Code's releases of Kleopatra (especially for Windows) while this ticket makes sense for every version of Kleopatra.

correct, this only affects encryption

I assume you only implement this for encryption and not decryption. The latter should always be possible.

I don't think we need a fallback. For the group configuration we can manually look in the old location. And for everything else it's okay to lose the configuration.

It works on linux (an presumable also on windows) but is ifdef'ed out since it requires unreleased functions from gpgme

Does not work on windows at all. Seems it doesn't any more on Linux, either (info Tobias)

works, VS-Desktop-3.2.93.391-Beta

works, VS-Desktop-3.2.93.391-Beta

ok, its even on by default, VS-Desktop-3.2.93.391-Beta