This may not be reproducible on Windows for the same reasons as T6813.

Me neither. But I take this since I can better debug this on Windows directly since this seems to be a windows only issue and it might be a build issue.

Not important for VSD 3.2 but yes I would like to see that fixed. Especially since we want the resolver also in KMail.

The only possible explanation I can see is that the signal-slot connections (using function pointers and lambdas) don't work because the progress dialog should be hidden when the job emits done() (which works on Linux with test_keyresolver).

I'm not seeing this on Linux with test_keyresolver as mentioned in T6566. Even after allowing test_keyresolver to be run in sign-only mode as seen in the screenshot.

Fixed with the above two commits.

To align the documentation of GnuPG, we should not use GNUPGHOME in FILES section.
It may be controlled by --homedir as well as GNUPGHOME.
GNUPGHOME is addressed in the ENVIRONMENT section, so, I don't think it makes sense using $GNUPGHOME}/trustedkeys.kbx.

Thank you. Applied and pushed in: rG260004747016: gpgv: Update used keyrings in doc FILES section

Belongs to T6789

The commits ^ added here accidentally linked the wrong task number.

We don't need that anymore in my opinion if customers do not complain that taskkill is too evil for them.

So the actual killing is now done with c5617e9f2426549cba54cb52f9faf9325f8e2929 we are using custom actions instead of CloseApplication to have more fine grained control when the steps are run. CloseApplication would only run in the main install sequence so basically only the Deferred part, but during an interactive upgrade like what one of our Entry users would do it would not avoid the first failure to kill a running gpg-agent this already would break the RestartManager support.

FWIW, the Fileversion is actually the Git revision in decimal

b) Is explained by the following documentation from: https://wixtoolset.org/docs/v3/howtos/updates/major_upgrade/

a) So with my current test upgrading from one beta to another it actually looks in the manifest and if you look there the beta230 of gnupg:

So with verbose logging /l*v inst.log (note the v) I finally saw the issue. My killing code works just fine.

tested with VS-Desktop-3.1.90.277-Beta

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.

Welcomewidget is broken now: Welcome to Kleopatra: [Kleopatra] instead of showing the version.

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