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

@gniibe: This is a pretty old bug; given all the changes of the last year, should we close it now?

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