Kleopatra has no influence on this. This does surely also happen when a new keypair is created on the command line.

Fixed. No backport needed because we use gpg4win-tools master also for VSD 3.3
@werner: gpg4win-tools needs to be updated in gpg4win master.

The file path of the group config file in line
https://dev.gnupg.org/source/g4wt/browse/master/src/resolver/resolver.cpp$171
has to be changed to the one in line
https://dev.gnupg.org/source/kleo/browse/master/src/kleopatraapplication.cpp$355 .
It may be best to add a function returning the default path to libkleo. Or to use the new path by default if no other path is passed to the c'tor of KeyGroupConfig. It's unfortunate that the path is GNUPGHOME/kleopatra/kleopatragroupsrc although the groups are also used by GpgOL and they should likely also be supported/used by KMail.

Yeah, I guess we can word this a bit less spec-like. It has more or less the same purpose as an admin PIN except that it's a 128 (?) bit key. And, if I understand correctly, it can also be used by the (admin) user to make sure they are talking to the correct card (if all cards are provisioned with unique keys). Kleopatra automatically tries to authenticate with the standard key so that we never see the prompt for the key unless we have changed it.

Backported for VSD 3.3

The additional changes were also backported for VSD 3.3

Backported for VSD 3.3

Maybe the title should be "Password - Kleopatra" (or similar) if the operation was triggered by Kleopatra.

Backported for VSD 3.3

Backported for VSD 3.3

GpgEX requires/uses Kleopatra so that only GnuPG would be left if you could deselect Kleopatra. And that's exactly what the simple installer installs because the simple installer is included in the Gpg4win installer.

Thanks for your feedback. Maybe the "minimal" install is missing a file. It's a beta version for a reason. We'll make sure to fix it for the stable release.

I have replaced the expiring test key with a new non-expiring test key.

Looks like gpg 2.2 doesn't emit a canceled status log message, but gpg 2.4 does if the problem only occurs with VSD but not with Gpg4win.

What components of Gpg4win other than GnuPG do you use?

Yes, that's by design. GnuPG is always installed in $INSTDIR\..\GnuPG by the gpg4win installer.

Backported for VSD 3.3.

Another data point:

$ locale
LANG=de_DE.UTF-8
LC_CTYPE=en_US.UTF-8
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=

Are you sure that the translations for gnupg are installed? On Tumbleweed translations are usually in a separate package. After installing the gpg2-lang package I get this when I force the Turkish translation:

$ LANGUAGE=tr_TR gpg --version
gpg (GnuPG) 2.5.2
libgcrypt 1.11.0
Copyright (C) 2024 g10 Code GmbH
License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Backported for VSD 3.3

Let's backport this for VSD 3.3 even if https://dev.gnupg.org/T7227#195685 is just a cosmetic issue. The first impression counts.

Apart from checking the gpgme logs to see if validation is enabled for the key listing this can be tested indirectly by verifying that the Status column isn't too narrow after generating a new certificate in an empty keyring in a VSD version (see https://dev.gnupg.org/T7227#195685).

In T7227#195685, @ebo wrote:

The status column is not wide enough.

There's the VERSION file that is used for customizing the About data for VSD and GnuPG Desktop. It's an ini format file that's read with QSettings.

Which dialogs? pinentry? If yes, then your assumption is correct. pinentry also gets the texts from GnuPG.

I'm not sure what we need for the clipboard that's not already in the SignEncryptWidget. I think the SignEncryptFilesDialog mostly adds functionality for the file handling. It might make more sense to try to share code that's implemented for the Notepad and then wrap this in a simple dialog.

There were three parties involved:

• gpgconf --launch gpg-agent
• gpg -k ...
• gpgsm --server followed by LISTKEYS command

Backported the latest change for VSD 3.3

In T7437#195688, @werner wrote:

I don't really understand the problem. After all gpg-agent seems to be started using gpgconf --launch gpg-agent which should handle the locking properly.

Maybe we could join the two dialogs, i.e. add the additional text and the Certify button to the import result window.

The title says "notepad". The description says "clipboard". What do you want?

We'll do this with QGpgME 3. And it's easy to add new functions by using the NVI pattern and, if needed, virtual functions in the attached private classes. I've been using this technique for quite some time now.

I think we have to use multiple different texts instead of assuming that we can use something general as "Detailed import results from %1" which fits all cases in all languages.

My comment referred exclusively to Tobias's "In the future [...]" comment.

"Tags" are stored with certifications. Therefore, I think it's useful and makes sense to show the Tags column in the Certifications view.

Isn't the name of the tab showing the imported certificates "Imported Certficates" or something like that? The filter "All" shows all imported certificates. And when you select the filter OpenPGP you see the subset of imported OpenPGP certificates. Therefore, I don't think it makes sense to add a custom filter.