I set the pin on my card, so this still works in kleo :)
When I had not set the pin, pinentry informed me correctly that the pin was not yet set and I got as an error "Nutzungsvorraussetzungen nicht erfüllt" so this works nicely.
With faked system time I was able to sign with a vs-nfd compliant brainpool key.

This is already in 3.1.26. I only wasn't sure if I should make another ticket for remaining issues before closing that is the only reason why it is still open

Well, the above mentioned cards are all with expired certificates and I did not use the cards. I could only check if some info about the certificates on the card is displayed in the smart card tab.
Is this is all necessary for the test if Kleopatra "accepts" those cards? That their contends are displayed? In that case you might count the ticket as resolved.
But I'm lacking a representative sample of testcards and don't feel comfortable declaring that all Netkey v15 cards are accepted on such cursory tests.

So the last thing to do here would be an NTBTLS release? Then we should make sure not to forget to do that?

This would of course all be also in vsd32

So if you tested this with the signature cards this can be resolved? My signature card still has the nullpin. I should probably set that to test it myself but if you have one and tested this why not resolved?

The whole part with colorschemes and high contrast mode and dark mode I have already tested.

For testing I would take procmon, filter for Kleopatra start Kleopatra from an older version. Save the log, take the current beta277 kleopatra and do the same and compare the number of lines in the log.

Same as with T6344 this is already in beta-277

This is in vsd32. But I am not sure what to test here. You could take a previous beta and look at the startup timining debug output which says "mainwindow shown" and compare that to beta-277? The mainwindow shown timing debug output is not part of 3.1.26

This is in VSD32-beta277

Testing in 2.4 will not be easy because it requires code modification just for testing. However, de-vs is not supported by 2.4 and the greater plan is to get 2.6 approved for de-vs.

yes, see it in VS-Desktop-3.1.90.277-Beta

works in VS-Desktop-3.1.90.277-Beta

@item handling with @table has been pushed.

RSA improvement is not that worth now.

OK. When we will need and do, I will open new one.

The fix is in 1.10.3.

Fix is in 1.10.3.

I'd prefer to not use the spawn helper at all. All currrent Windows versions allow to decide which handles are to be inherited and thus there is no more need for the helper.

ok, opened T6819 for the separate button.
The rest is ok, I think. As long as we display keypairs in a single entry, it can not be helped that they may appear valid in the certificate list but are invalid for signing or encryption subkeys.
We display that here correct for the respective contexts.
Therefore closing,

works as advertised, VS-Desktop-3.1.90.277-Beta

Sorry @ebo tested this on Windows with 2.2. I myself should have tested it since the test is trivial and only took me about 30 seconds to type. Similar to T6701 this should have never reached the QA stage. I am including myself now that we have someone for QA that I test my own changes less. We need to talk / think about that in our whole team. We developers should test more before sending an issue into QA.

What about the second part of https://dev.gnupg.org/T6742#176528? Should I make a separate a11y ticket for that with low prio?

Since I did not have a valid signing cert on that dev keyring I only tested with encrypt,...

@gniibe: This is a pretty old bug; given all the changes of the last year, should we close it now?

Works with VS-Desktop-3.1.90.277-Beta

As discussed in chat has nothing to do with only signing. Only that signing makes it easier to get errors by cancelling pinentry or entering bad passwords.

Works for the reported and important cases, Tested with VS-Desktop-3.1.90.277-Beta

You are creating a signed archiv? Why - gpgtar is used for encryption.

I reprodcued this with a simple: "gpgtar --status-fd 2 --verbose --create --sign -u foo@bar vimfiles > foo.tar.gpg" on the command line. Which gives me the proper status lines but then ends up in kleo with general error.

I tested it some more. Gpgtar reports proper erors like:

I edited the task description.

Ok maybe because of the task description with timeout. But for a Cancel to report "General Error" that is unacceptable.

In T6575#178532, @ikloecker wrote:

The same happens when the pinentry is canceled, i.e. General Error is reported although in this case the dialog should simply be closed (because the user canceled the operation).