I would keep the "create group", too.

In T7515#198012, @alexk wrote:

Regarding the suggest list I would change the following:
but keep:

• Enable/Disable Certificate

Regarding the suggest list I would change the following:

Needs to be tested/verified by other developers. In short you do

./autogen.sh
cd packages
./download.sh
cd ..
./build.sh --appimage --builddir=...

If you omit the --builddir=... option then ~/b/SRCDIRNAME-appimage will be used.

Building an AppImage including Kleopatra and Okular works now (again) in the gpg4win-5-branch.

aheinecke: Yeah, but I did quite some changes to build.sh for a real out-of-source build (w/o copying files)

Just so that its not overlooked and you are meaning something different. But I had the Qt6 / KF6 branch working with the --appimage parameter.

Fixed.

In T7515#197774, @TobiasFella wrote:

I'd suggest removing:

I'd suggest removing:

If a single OpenPGP certificate is updated then we now show the same detailed information for the update from WKD as for the update from a keyserver, i.e. if the certificate didn't change via WKD then we say so.

I think there's some confusion.

changed the workboard to gpd5x as this is still the case in Gpg4win 5.0-Beta versions.

Gpg4win-5.0.0-beta32
Works!

Gpg4win-5.0.0-beta32:
The remaining attempts are listed:

You need to be asked this question when you restore the backup of all of your keys or when you migrate all your secret keys to a new computer.

The situation seems to be even more complicated: If I click "yes" or "no" in this dialog, I *do* get asked for all certificates that are being imported. If I click "Cancel", no more dialogs show up.

I'm not sure what Kleopatra should do differently. Kleopatra relies on the error messages provided by gpgme which in turn relies on gpg's status messages.

FWIW, If a fix is really required for gnupg this will be done for gnupg26 and not for gnupg22. However, it is mostly a kleopatra issue.

Hm, "Names for the certificate" seems wrong to me. Shouldn't it better be "Names in the User IDs [of this certificate]"? I would leave of the part in [] as redundant. Likewise for the mail addresses.

Thinking about this some more, i came up with some more ways of showing some nice-to-have information in the tooltips:

works with VS-Desktop-3.2.94.481-Beta

works in VS-Desktop-3.2.94.481-Beta. The "Trust Root Certificate" is no longer offered in the context menu.

works in VS-Desktop-3.2.94.481-Beta

"Tested" with VSD-beta-478, looks as expected

works with VSD-beta-478

Works fine in VSD-beta-478

https://invent.kde.org/pim/kleopatra/-/merge_requests/355 makes both components use the same tooltips; we can then change both when we decide on what exactly to show in the tooltips in general

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.

The additional changes were also backported for VSD 3.3

https://invent.kde.org/pim/libkleo/-/merge_requests/178

Backported for VSD 3.3

There's a different (but very similar) bug here for RSA keys; fixed in https://invent.kde.org/pim/libkleo/-/merge_requests/177

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

We noticed in the above mentioned ticket that this needs to be backported

as far as I understand both the Gtk and Qt implementation are using pinentry_get_title which does the /proc stuff, but this is only on Linux. On Windows, pinentry_get_title will return the value set in pinentry_init, in our case pineentry-qt or pineentry-qt5.

Check out the GTK version which scans /proc for the process to find the command line. Very handy for ssh sessions.

I can still reproduce the issue with VSD beta 478