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.

Adding vsd33 for testing with next VSD

This can be tested with T6879: Kleopatra: Add support for adding an ADSK.

respecting the "disabled" state is ready for testing; the rest won't be done on this ticket

backported

should be ready for testing

backported

backported

backported for vsd33 to avoid conflicts with changes for T7076

backported

backported

The changes where backported for VSD33, but they have little to do with the original request. They only address https://dev.gnupg.org/T6072#167392

backported

Backported for VSD

Browsers automatically add an increasing number to the file names of downloaded files in case of a conflict. I think that's a strong indication that people don't like to be bothered with such things. But let's see if people complain.

Makes sense. Then default-new-key-adsk needs to be exported by gpgconf, so that gpgme/Kleopatra can use/show it.

To add some (unrepresentative) statistics: My normal keyring contains 552 keys. 5 keys have a single revocation key. 1 key has 3 revocation keys.

What's the use case for multiple designated revokers? I don't think we should optimize Kleopatra's UI for something that's in theory possible with the OpenPGP spec, but which in practice will never occur for a productively used key. The standard use case is that the company wants to be able to revoke the keys of their employees, i.e. there will be a single revocation key.

I guess the status should be set to Testing?

In D545#6468, @sandro wrote:

Is supporting Python 2.7 such a high priority? That version of python is super duper EOL and this might be a good opportunity to drop support for it.