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

For my testing environment, I have this patch for now.

Testing dirmngr by /home/gniibe/build/mingw-i686/gnupg/bin/gpg-connect-agent.exe --dirmngr 'loadswdb --force' /bye (configured distsigkey.gpg beforehand), I confirmed it works well now.

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?

Fixed in: rG862448216035: common:w32: Fix INEXTRA handling.

All applied and more fun with cherry picking in the future ;-)

Done for 2.6.

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.

In future, when spawn function API is used by libassuan (and stable), we can support gpgme with no gpgme-w32-spawn.exe.
(And it will be simpler, just using native functions in libassuan, instead of replacing ones by assuan_system_hooks.)

This is related to T6818

I guess the status should be set to Testing?

In D545#6468, @sandro wrote:

Is supporting Python 2.7 such a high priority? That version of python is super duper EOL and this might be a good opportunity to drop support for it.

The unexpected behavior of the MAPI store needs to be tested and handled. I had indeed forgotten about POP Mail in my concerns not to leak decrypted mails back to storage.