tested with VS-Desktop-3.1.90.277-Beta
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Nov 15 2023
The reason for this is that this still uses the libkleo::gpg4win class for the version info, the about data in GpgOLs help dialog should be similarly broken.
Hopefully fixed for good.
We decided that this is an invalid issue most likely related to the test cert / test card. We have tests done with real world Signature cards with brainpool and they worked.
Screenshot with details about the key in question. It might be a weird one since it does not have usage flags set. But this is the only brainpool key on my test card and it shows up for encryption in Kleopatra.
You can't decrypt using the Esign application on such a card. Please provide more information off-tracker.
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.
Nov 14 2023
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?