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.

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.

Thanks for the reviews. And your beautiful work, by which I also mean the response to the feedback and how you managed to work with phabricator. I will commit the patch on your behalf then later.

Well in Gpg4win it actually works better :) At least there the configuration files are all in one place (or mostly, or should be). Anyway a difficult issue which I am only planning to touch when we do the migration to Qt6 since this is heavily Qt releated. But the current plan (which might change) is to do that for the GnuPG VSD summer release which will be the next feature release after 3.2.

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"

So as a replacement for what we have in Kleopatra this would work.

To be honest. While I get that the customer wishes for even more non standard behavior and I somewhat agree in the case of smime that it makes more sense to encrypt to an expired key.

Well I guess T6805 is now the followup ticket that I did not create when I just closed this issue as Wontfix. Ingo can you take T6805 and do what you wrote in your last message here?

This is an incarnation of T6685 while we decided to deprecate that job we did not open a ticket to do it and forgot about it. So we did not notice that it was still used in the keyapprovaldialog. Fix is to replace it there with the correct key generation job.

Thanks, I will test this and if it works as expected I would also put it in 2.2. since it was pointed out to me from a customer at our approval institution and I think they will be glad if they see that this is gone in the next release and I don't see any regression risk associated with that change.

To be honest, the only backup worthy settings file of kleopatra is the kleopatragroupsrc right now. Most other settings are pretty much only for convenience I would not even bother to back them up. When something important is configured by the administration that should go through the registry. As we recently noticed, through talking to people at froscon and with the BSI the most common case was that our kleopatra settings were actually never updated or only saved by accident.

Well the icons are there. So I don't think this needs more QA.

This will definitely not be changed for 3.2 it will be a very invasive patch with a big regression risk and which does not make real sense to do before we switch to Qt6 since it involves patching Qt.

When I created the GnuPG VS-Desktop MSI Package I messed up and forgot about a file that Gpg4win writes where to place the config files.

Tested both on Windows and Linux and it works now.

I think this works as intended.

So I just checked how Outlook does this. It saves its temporary files not into temp but into:

C:\Users\Andre Heinecke\AppData\Local\Microsoft\Windows\INetCache\Content.Outlook\PK5RYJME

(Last part is only random) Now the fun part is that when you close outlook, it just closes the Windows in which the files are open. In your case it would close the image viewer and then deletes the file. The files are write protected so there is no real data loss. So for a high security mail client that might not be the worst behavior. Maybe we should do it like this, too: https://learn.microsoft.com/en-us/windows/win32/api/shobjidl_core/nf-shobjidl_core-ifileisinuse-closefile I mean we want to be an Outlook plugin so why not do the same?

Yeah there were some logic errors with this but I think I caught them all.

Since 23.08.2 the crash is gone again as expected. Thanks. Btw. do you know which was the first version that had this crash? I am a bit worried that our fellow debian stable users in the office might be affected with the next debian upgrade. Since we use signed / encrypted mails a lot. :)

This works very well. I would like to add some data though about the number of reduced syscalls before resolving this.

So with my ryzen 9 on tumbleweed:

So priority Normal for "have a way to show html in QTextBrowser" and after that move it to prio low. Our SecOps explicitly state that HTML mails should be avoided.

For now I am for the KMail approach with QTextDocument. So if we have multipart/alternative show a button that HTML is available and then the user can decide (e.g. if the mail is validly signed) to render the HTML part in QTextDocument. This might give us also an idea how well this works overall. And then let us wait for now until we get to the real GpgOL.js use case. For the customer we talked today is a bit special in that he mostly wants to have a way to view decrypted mails in Outlook. That is something we do not want to compete with.

Changing the prio to normal as we have this now and want to improve on it.