Merci vielmals. Cherry-picked.

I cherry picked it anyway. See my notes in T6813 I think I will at least workaround that one tomorrow.

Mh, I found some commits related to that 0796e04aa43c4500fb0f2c378b9a6cadf53a0a94 a43080fb0472afb46726cc555efffa102de9c7cc 810ed7b374f38eb7e038a83a557c8b6b91a65da3 if I remember correctly I even discussed this with Thiago and or David Faure back then and we figured it was a problem with default arguments. And there might have been a difference in KDE Compile settings and the compile settings with which QGpgME are compiled. It is pretty weird though even after some searching I can't find an initial commit from me that might be more verbose about the topic then just "Again new style connects won't work".

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.

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.

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.

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.

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.

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.

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

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.

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.

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

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.

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

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.

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

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.

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

I want to test how this behaves with some random data which is not a mail. Otherwise I think this is resolved.

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.

Well the checkbox is before this dialog. This dialog only comes up if you have checked sign or if your administration has checked sign for you (which they _should_ only do if they also ensure to give you a certificate). But usually this should not come up this way.

I am mostly sure that for the majority of our users "sign" means the "signature" of the email. So the bottom text below an email so I try to avoid that wording as much as possible. It is only visible in the "advanced" sub options of GpgOL which I think should only interest people who actually know what the context "sign" means when clicking the button "sign".

I have no idea why it should make a difference whether the error message is shown after OpenPGP certificate creation or after copying a key to a smart card. Everything should run in the main thread. I'll add some more debug output for further investigation.

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.

In T6701 it was reported that this also occurs if we block outlook long enough in the send event and not only if we disable the window like we do with the async encryption.

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.