I mean what gpg --export gives Werner.

Do you mean the pubring.gpg format or the on-wire OpenPGP format; ie. what gpg --export gives?

Not if there are technical reasons to keep the address. BTW, you solution would not help because the fingerprint of key is personal data in the same way as a mail address.

Werner, according to GDPR if a user upload a key with it's name and email address he or she may be able in the future, to ask for removal of this information.
How is this going to happen, to a keyserver, accordingly to your suggestions?

Will go into 1.19.0

A tool can't make some thing GDPR compliant - this is all about policy and informed choice. There is actually no problem if you allow ppl to decide whether to upload personal information to a public service.

I think Werner backported some missing functionality to GnuPG 2.2. Please retest with the next version.

ready for testing

I wrote T6412: Kleopatra: Inform user if some files were not extracted from encrypted archive to inform the user about not extracted files. I think this shouldn't block this issue because special files probably don't occur in normal usage of GnuPG VSD.

Closing. This will be tested with T5478: Kleopatra: Performance problems decrypting and encrypting large Archives.

I think letting KIO show the progress is okay for now. I hope it also works on Windows (if showing progress is necessary).

If it's possible to search for any keys on an LDAP server, then gpg's LDAP support could probably map "*" to the required LDAP search filter. I'm pretty sure that (modern) keyservers don't allow listing all keys.

FYI: Quite some more days than a few passed by. I still did not found the time for this, sorry.

works. tested with VSD 3.1.26 (gpg 2.2.41) and keyserver entry in dirmngr.conf only.

works, server can be added to dirmngr.conf via kleopatra

works with AD, too. Even with an "a" ;-)

Hi @werner,
I understand we should use --with-libksba-prefix, but it doesn't work:

I changed the title of the issue to make it about adding the warning. I also think that is a good idea to avoid confusion / accidents.

I disagree. Unless customers explicitly request it users should be able to trust root certificates manually. I do not see much difference between this and allowing users to certify their own certificates.
This can be required when a user wants to encrypt something to an unknown certificate, regardless of VS-NfD or not.

That is not a bug but required for backward compatibility. See me/ksba.m4:

I would suggest that with the VSD 3.2 we make --no-user-trustlist the default via the corresponding registry entry and explain how to use --sys-trustlist-name to use a custom trustlist.

Hint: When the user disabled GpgOL -> Automation -> Automatically secure messages in the configuration of GpgOL he could see the email body again.

Yes, the installation was with the unmodified Installer GnuPG-VS-Desktop-3.1.26.0-Standard.msi

This isn't a support forum. You'd better ask on the gnupg-users mailing list before assuming that you found a bug.

Are you using an actual GnuPG VSD installer? I'm asking because, as far as I know, several actions are disabled via immutable config entries that are only shipped to customers.

Closing this one - see T6378

Fixed in 2.2 need to check 2.4

Ooops. We do not have the automatic chnage of key type in the WRITEKEY command of scdaemon. This is only done when generating a key.

There is actually a regression wit Yubikeys. The fix for 2.2 is in T5100: rG08cc34911470 - for 2.4 I need to check

I agree. Something called READ... shouldn't change existing data. (Updating existing data to a new format that doesn't alter the semantics of the existing data is okay.)