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.

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

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.

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

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,...

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).

Some observations on Linux:

• If I cancel sign&encrypt archive while the encryption is still running then Kleopatra removes the .part file. I didn't see a running gpgtar or gpg process after I canceled.
• If I cancel sign&encrypt archive by canceling the pinentry (asking for the password of the signing key) then the gpgtar and gpg processes keep running for a short time and Kleopatra still shows the progress. Eventually Kleopatra shows an error (General Error) instead of simply closing the window (-> T6575: gpgtar: General Error is emitted instead of more specific error codes). In this case Kleopatra didn't (have to) remove the .part file because it was already gone.

Then we need to kill it with fire! :) Or maybe some context is still open at the time that keeps the process alive? I could investigate on windows. But on linux it might be easier to just breakpoint kleo right before the delete and do an lsof on the file? even though on linux the deletion would likely succeed.

Ok. With a simple group with one valid and one expired certificate it looks fine:

Exactly. If possible. Kleopatra tries, but it's not able to remove the file. Because some process in the background keeps it open.

In T6584#177453, @ikloecker wrote:

We now use a temporary .part files when creating the archive. On success, they are renamed. Otherwise, they are removed (if possible).

With VS-Desktop-3.1.90.277-Beta the temporary file ends with .part now and is renamed properly when the job ends successfully.
But it is not removed when the job is aborted.

works better than I expected. With VS-Desktop-3.1.90.277-Beta now there is no delay any more, neither after nor before the new message window

My Idea is now that we will will write the file, Then open it natively with CreateFile https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilea (With FILE_SHARE_READ | FILE_SHARE_DELETE) then store the Handle. Call QDesktopServices::openURL on it. And if we are closed we call DeleteFile on all our open Handles.

Ok closing, remaining issue is in T6813

This can be also reproduced easily on Linux with test_keyresolver from libkleo:

After reading the initial description of this, I think that might even be a yet a different bug. For which we then would not yet have a ticket. :)

The issue for that is: https://dev.gnupg.org/T6566 so I think this can be resolved here?

No it is just not properly selected after generation but it is there. I think there might even be an issue for that already. But definitely not something related to vsd 3.2

With VS-Desktop-3.1.90.277-Beta the generated key is the default RSA 3072.

Yes it is in the gnupg beta235 which is part of vsd-beta 277

I don't see how it removes the file immediately. Only on job->error(), or am I missing something? It also leaves write permission so that is something that I would not do.

Btw. what does KMail do? It remove them afaik when you close the message.

Need to check if this is in the beta or not before moving it to the QA board.

Yeah we should fix that before a release. Otherwise we might get disgruntled customers that will notice that their VS-NfD files are lying around unencrypted. First step IMO should be to make the files write protected. And then CloseFile on them when the viewer window closes. Btw. what does KMail do? It remove them afaik when you close the message.

Ok closeapplication will not work because:

Note to self.

@CarlSchwan I think this one should be fairly easy to fix and I would really like to see it gone before the release, so I am tagging it for the release and raising the prio.

So some research led me to believe that using taskkill from MSI is not uncommon. But most stackoverflow solutions did not work for me. I have one solution that works, though but that opens a terminal window for each process we try to kill. I don't want to use wscript to avoid that, since an installer that executes visual basic is IMO even more evil then an installer that executes taskkill. Both are not really the MSI way, but while we could fix our processes without a WindowMessage loop to die nicely this will not work for an upgrade to vsd32.

That it takes so long the first time is to be expected since we are hitting the dirmngr timeouts. I wonder though why it would be much faster in 3.1.26, if anything i would have expected that the timeouts are now shorter.

Since this is a bugfix and it was related to 6742 with some commits having overlap i decided to also pick this for the 32 release branch.

Discussed this with ebo. This is a bugfix that should be in the release even though it is multiple changes I will cherry pick them over to the release branches.

When testing with the viktor-gnupg testcertificate I get the new warning message instead of the not very helpful "no name" error in 3.1.26.
But it takes at least 30 seconds to get to that message (the error message in 3.1.26 came up much faster). And when acknowledging the warning it again takes almost as long as before until the message is sent. And in 2 out of 3 tries the Compose Window remained open, so that it looked like the message was not send. Clicking again on Send did not make anything happen, though. And checking the mailbox showed that the mail was sent already.

That sounds very good.

We are now generating a key with whatever defaults gpg uses.

We discussed this at length again. I would not veto a change that would allow users to encrypt to expired S/MIME certificates but the main use case I had in mind here was with regards to "Some error" happening when encrypting ( like T6545 T6398 ) . So that in the keyresolver everything is green but you cannot encrypt. Or that you have an incomplete certificate chain or an untrusted root certificate and it will take your administration some weeks to mark that as trusted. That makes this feature a bit hard to test so ebo mostly tested with expired certificates. (And I know that technically you can't verify if a cert is expired or not if you have an incomplete chain). A better test will be with a fully valid cert that has an unreachable CRL distribution point. I have such a cert and will give it to ebo. So she can test again and if that works as intended -> Key resolver green -> Error -> Allow to encrypt anyway but not vs-nfd compliant. I think we can set this issue to resolved.
The whole question regarding expired / non expired is a different topic on which, as I said, I changed my mind. You can easily explain to users "You cannot encrypt to expired certificates" but you cannot easily explain "you cannot encrypt to support@greenbone.com because they have unsupported cert extensions in their certitifcate"