Works with VS-Desktop-3.1.90.277-Beta

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.

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.

I learned about how @item is handled by TeX. By @table command, user specifies how to handle the item line. In the case of GnuPG, it is like:

@table @gnupgtabopt
@item --version
...
@item --help

(Emacs uses @table @samp, while GCC uses @table @gcctabopt.)
And @gnupgtabopt is a macro which is expanded to @code{\body\}

Reopened as I noticed that the last testmail had an empty body in my sent folder. And I am sure that I wrote some text. Please check.

That's right: -K is merely a -k which prints only keys which have at least one secret key or a stub key (for smartcards) available.

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

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.