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.

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

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.

Well, virus checkers aren't perfect. If 1 out of 65 checkers reports a finding, then the probability that this finding is a false positive is very high. You would better report this to the vendor of NANO-Antivirus, so that they can fix the false positive warning.

This pretty much highlights a general problem of groups: If the distribution groups for the email client are managed independently from the certificate groups then there will inevitably be discrepancies. The obvious solution is the usage of groups managed by a central service for email addresses and certificates. (Or an encrypted mailing list service.)

If agent_write_shadow_key does now also check for an existing private key file, then I'd replace following code in cmd_readkey:

if (agent_key_available (grip))
  {
    /* Shadow-key is not available in our key storage.  */
    rc = agent_write_shadow_key (0, grip, serialno, keyid, pkbuf, 0,
                                 dispserialno);
  }
else
  {
    /* Shadow-key is available in our key storage but ne check
     * whether we need to update it with a new display-s/n or
     * whatever.  */
    rc = agent_write_shadow_key (1, grip, serialno, keyid, pkbuf, 0,
                                 dispserialno);
  }

with a simple call of agent_write_shadow_key (removing the maybe_update flag) and let agent_write_shadow_key do all checking for an already existing private key file and whether it's a stub file that needs updating.

Could this be a duplicate of T4924: pinentry: pinentry-curses doesn't allow to set no password or weak passwords on 80 char width and smaller terminals?

Make sure that the fix doesn't break "gpg --edit-key; keytocard; save" which explicitly does replace the private key with a stub file.

Just had a look at the development version. There the observation is exactly the opposite, i.e. the Tags columns of the certificate list and of the user ID list are empty, but the tags are shown in the Tags column of the certifications list.

I should probably add that Kleopatra calls this command when reading a smart card to create the key stubs if necessary. Kleopatra does this since gpg4win-3.1.24 (according to the tags) and the KDE Gear 22.04 release (see T5782: Kleopatra: Smartcard unusable secret key until used via command line).

Your report lacks any useful information starting with the version of gpg you are using. Did this ever work? What did you change? Did you probably upgrade the system and have previously been using gpg1, but are now using gpg2?

I have analyzed the problem. It is caused by a serious regression in gpg 2.2: https://dev.gnupg.org/T6386

Arguing with the documentation of a functionality Kleopatra doesn't make use of makes no sense. Kleopatra uses gpg-agent's "KEYTOCARD" command which, unfortunately, lacks a good documentation.

Ready for testing. In case of a file name conflict the users are now offered to Overwrite the existing file or to Rename the new file (i.e. save it with a different name). If multiple output files are created (e.g. when encrypting multiple files separately), then the users are additionally offered the options "Overwrite All", "Rename All", "Skip", "Skip All".

What do you want to achieve by using multiple encryption subkeys? Do you realize that gpg will always encrypt to one subkey (unless you explicitely specify multiple subkeys), i.e. you won't be able to decrypt on device 1 what you have encrypted for device 2 and vice-versa. Usually, this makes little sense because it seems you want to be able to decrypt anything on your main machine.

If 3.1.26 only offers RSA algos, then Kleopatra obviously assumes that the smart card only supports RSA and therefore doesn't offer the transfer of Brainpool keys.

Which algorithms are offered when you use "Regenerate Key"? What's the output of gpg -K --with-colon <key_id>?

Kleopatra simply copies the content of the corresponding *.key file in the private-keys-v1.d folder. If the *.key file contains a shadowed key after issuing a KEYTOCARD --force [...] command followed by a SCD LEARN --force command (note the SCD!), then gpg-agent is to blame.

Works now for gpgme. Thanks!

Works for me with gpgtar (GnuPG) 2.4.1-beta21. I haven't verified this with 2.2.x.

With the current development version I get

$ gpg --version
gpg (GnuPG) 2.4.1-beta21
libgcrypt 1.11.0

Finally, what's your use case? gpgme_get_key() is meant to be used for getting individual keys. It's not meant to be used to get 1000 keys in a loop.

Moreover, if you have performance problems on Windows, then it's not the best idea to strace the code on Linux.

Just asking the obvious: You are using an optimized release build for your benchmarks, right?

Okay. So the problems with "file type 1" seem to come from git using hardlinks and tar storing them as hardlinks, but gpgtar ignores them on --decrypt. This would also explain the larger size of the archives if gpgtar stores the hardlinked files multiple times in the archive. Take home message: Don't gpgtar your git repo!

Running gpgtar directly only gives slightly better results. The following

GNUPGHOME=~/xxxx gpgtar --batch --status-fd 2 --gpg-args --enable-progress-filter --encrypt --gpg-args --always-trust -r D5E17E5ABC11F4CD060E02D41DD0D4BAF77BE140 -r C02C4012C09B2AE33921CF87577E88AC284DC575 --output - --directory /xxxx src >src-gpgtar.tar.gpg 2>src-gpgtar.log

took about 31.1 seconds.

"file type 2" may refer to symbolic links.

I did some tests. I encrypted the g10/src folder which contains multiple repos (33098 files) with a total weight of about 1.4 GiB.

I made the condition for calling the verify handler more strict by checking if err is a NO DATA error. This should minimize the risk of regression.

This did

AllowSetForegroundWindow(pid == -1 ? ASFW_ANY : pid);

on Windows.

I see two possible solutions.

Nobody stops you from removing any unwanted keys from the keyring. Nobody stops you from importing all keys to a temporary keyring (using a temporary GNUPGHOME), export only those keys you want in your proper keyring, import those in your proper keyring, and then ditch the temporary keyring (resp. GNUPGHOME). gpg doesn't stop you from doing any of this.

In rGeae28f1bd4a5632e8f8e85b7248d1c4d4a10a5ed#76889, @sandro wrote:

The profiles are not any longer useful because global options are way more powerful (/etc/gnupg/gpg.conf et al.).

How are distros supposed to set a value for pinentry-program now? gpg-agent only looks for the config in the user directory and fails to find pinentry if it is not in PATH.