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

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.