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

Thanks for commenting from the other account. This allowed me to disable the account. Deleting and account is hard in Phabricator thus we do it only very rarely. But disable is basically the same.

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.

and before you say there's just a "remove my account" button on the home screen, using it gives an error:

It's virtually impossible to find any "delete account" (or "disable account") button.

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.

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

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 like the explicit check boxes in the file encryption dialog more than this "hidden" combo box entry. (BTW, the file encryption dialog says "sign as" and "prove authenticity (sign)" but in this case there's little potential to confuse "sign" with email signatures. The wording should probably still be unified.)

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 just verified the new account. Please delete (i.e. disable) it yourself - I can't easily figure out whether it is really your account.

Sure. But in both cases they get back an error code and then, back in safe Kleopatra territory, they convert this error code into a string. I don't see how this error code to string conversion should have anything to do with the way the commands triggered the operation. Both conversions should happen in the main thread, so that the state of libgpg-error should be identical. The logging will show if in the still failing case libgpg-error is not switched to UTF-8 for localized texts.

Problem seems to be that there is no ~/trustedkeys.gpg file and that the fallback to the kbx file does not anymore work. I can replicate that with 2.40 and 2.4.4-beta.

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.

The same happens with a very recent 2.4:

$ gpgv --version
gpgv (GnuPG) 2.4.4-beta56
libgcrypt 1.11.0
Copyright (C) 2023 g10 Code GmbH
License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Ok closeapplication will not work because:

That version of gpg is too old that I will look at it.

MRs for reference:

I have prepared a first patch:

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.

I need the S/MIME group if I shall look into this. Are you sure that all S/MIME keys in the group can be used for encryption? Groups containing sign-only keys (OpenPGP or S/MIME doesn't matter) are never offered for encryption. That's why we wrote T6722: Kleopatra: Forbid adding non-encryption keys to groups.

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.