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.)

Ignoring the error seems to be the best choice. I also think that --force should not overwrite a shadow key file. It seems safer to explicitly delete the key first. A --force option for READKEY does not sound right.

I did some reworking and the outcome of the READKEY command is now (agent log):

I checked it: There was an empty bin/gpgconf.ctl, and there still is.
Trying it again today, I still get error messages most notably about failed self-tests, but surprisingly the window is no longer empty.
Instead it seems to take an eternity (minutes, actually still not finished after three minutes) until the certificate cache is loaded.
Maybe the problem is the "Check Point Endpoint Security" being active on the client. It looks as if it prevents use of Kleopatra.
As I don't have administrator rights ("for security reasons"), I cannot analyze what's actually going on.

I never made a threat model. But definitely *any* cracker, should be out of my system, either from governmental agencies or from a kiddo in Russia.
I know that I have someone that is remote accessing my machine, since I got some tells. And that this cracker have used my Emacs text editor.

For non-vsde-enabled installations the green check symbol is okay because in the given context (encryption) it indicates that the key can be used.

Seeing that there are "groups" in Kleopatra, I read the docs, and they suggested that the groups are for addressing multiple recipients.

Settings -> Configure Groups.

It seems that you are missing the step "Create a new file called gpgconf.ctl in the folder Gpg4win_Portable/bin."

I am pretty sure we have the same problem in 2.4 - due to different access patterns it might not exhibit itself.

Smartcard PINs are different from passphrase for on-disk keys. Once a PIN is entered the smartcard is unlocked as long as it is powered up. In theory we could power down and power up the card to lock it. The question here is what is your threat model? If you have malware on your system it could simply brick your token or, more common, peek at your PIN.