The problems with colors in high contrast mode were addressed with T6073: Kleopatra: Fix issues with high contrast resp. inverted color scheme. I'm not sure what's left to do. Setting to Testing for getting feedback what's missing.

Backported for VSD 3.3

In T6073#173463, @ebo wrote:

On windows the main window looks ok with high contrast mode black. But with dark backgrounds some items in other windows are not readable:

I'm setting this back to Testing. In the meantime GpgME has been updated to a 1.24.0 beta version and includes the needed functionality.

I backported this trivial fix for VSD 3.3. Support for drag&drop of certificates from Kleopatra to other applications or the desktop was added for VSD 3.3 (T6893) and it shouldn't confuse the users.

Ready for testing. Backported for VSD 3.3.

Backported for VSD 3.3

I checked who eats the second valid signature after the first invalid one. It's gpg in batch mode.

The part after the colon in "The signature is invalid: Invalid Signature" is the error returned by gpg that's responsible for the invalid signature. It could potentially be some other reason. Of course, we can simply not show the error anymore. Obviously, this would remove some details, but maybe that's okay. People could still look at the audit protocol for further information.

In T6867#187289, @ebo wrote:

After discussion we concluded that showing all signatures in one detached signature file is something we want soon.

I verified that I can still build libkleo and kleopatra for gpg4win/24.05 (Qt 5) and master (Qt 6).

I'm wondering whether we are hit by undefined behavior. https://en.cppreference.com/w/cpp/algorithm/sort mentions some conditions that must be met for (un)defined behavior. Or it's a bug in gcc or gcc's STL. I added some debug logs to the comparison lambda. The first comparisons look fine but after a certain number of comparisons it crashes in the debug logging (when it tries to access the primary fingerprint).

The usability challenge does already exist today because Kleopatra allows to encrypt all files separately. Currently, all encrypted files are written to the same output folder. Which is highly problematic if some of the original files have identical names. Encrypting the individual files in-place would avoid the problem of name clashes.

It would be helpful if gpgconf --list-options gpg listed the default-new-key-adsk option so that Kleopatra knows whether the option is set.

I updated the certificates of Werner, Andre and you and got as result "The certificates were updated.", i.e. plural, for both, keyserver and WKD. Singular could mean that only updates for one certificate were found.

That the first result is selected is a side effect of making the certificate list more accessible. When the lookup finished, then the certificate list gets focus so that the users can immediately interact with the result. When the list gets focus we unset and reset the current item which triggers the selection of the item. And that triggers an accessible event (so that the user knows than a list item was/is selected).

Querying WKDs for keys not retrieved via WKD leaks information, i.e. a (fake) WKD could track who is looking for keys. KDE's privacy-by-default policy doesn't allow such a setting to be enabled by default. (In VSD you can enable it for certain customers who don't have a problem with this.)

Note for testing: To reduce the PUK counter to 0 you have to enter a wrong PUK for "Unlock Card". The wrong PUK must have at least 8 characters. Otherwise, gpg-agent will consider the PUK wrong without even asking the smart card so that the smart card doesn't get a chance to reject the PUK and decrease the PUK counter.

When VSD33 has been updated to integrate the fix/commit then this can be closed (i.e. set to vsd-3.3.0) without manual test, in my opinion.

The (rather trivial) changes where reviewed by Sune. And it's not really a very important issue. Therefore, I'll set it directly to resolved.

Merged to VSD33.

I can confirm that Kleopatra reports "The certificate was updated." when updating the certificate werner.koch@gnupg.com although gpgme reports "unchanged: 1" as ImportResult. Kleopatra even reports "The certificate was updated." under WKD for a locally generated test key that's not available via WKD. This should be fixed.

gpg uses "Remaining attempts:" for the pinentry. I'll use this also in Kleopatra so that the users can more easily recognize that this is the same information.

One idea to solve this would be to use a different model because our KeyListModel doesn't allow multiple entries with the same fingerprint. This would also allow us to get rid of columns that make no sense in this workflow like the User IDs column (validity checks are impossible).

In T7067#187088, @ebo wrote:

Should I make a new ticket for making the origin column default for the search?

Note that signature notations are now always loaded (after the initial key listing which is done without them). I have enabled this to make features like T6766: Kleopatra: On export, inform user about uncertified user IDs which require all certifications just work, without having to remember to load certifications or signature notations when needed which would just lead to bugs because one would obviously forget to remember this.

Done. This is how it looks like:

I gathered the CHV-STATUS information of a few cards.

This works for me. And it also seems to work for ebo with VS-Desktop. Setting to Testing, but I think it can as well be closed without another test given that ebo already tested it.

Works for me for a dark blue (R&S) smart card and a Genua smart card. See T6847: Kleopatra: Show S/MIME certs for PKCS#15 cards in smart card view.

I think the correct fix is to C-cast the return value of GetProcAddress to the type of func which we would have to define with a typedef as in the example for GetProcAddress: https://learn.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-getprocaddress

This should probably be tested with T7150.

This doesn't seem to work. I get

$ gpg --version
gpg (GnuPG) 2.4.6-beta4
libgcrypt 1.11.0

gpgme and the C++, Qt 5 and Python bindings can be configured, built and installed with the following commands:

./autogen-all.sh  # runs autogen.sh for gpgme, lang/cpp, lang/qt and lang/python
mkdir build
cd build
../configure --prefix=/opt/gnupg/2.4 --enable-maintainer-mode --enable-languages="cpp qt python" --enable-qt-version=5
make
make check
make install

i.e. the only difference is that one needs to run ./autogen-all.sh instead of ./autogen.sh. And that one needs to enable the bindings and specify the Qt version. (By default, the Qt 6 are built if Qt 6 is found.)

The current proposal has been pushed to the branch ikloecker/t7110-nested-bindings-packages.