Yes this would be a bit more consistent. The idea was that when decrypting there is not much to see in the window so the only actionable item should be at the top. But consistency is better.

! In T6561#172087, @werner wrote:
FWIW, gpg shows the actual cipher and encryption mode with -v. For example

FWIW, gpg shows the actual cipher and encryption mode with -v. For example

In T6561#172083, @werner wrote:

s/CBC/CFB+MDC/

s/CBC/CFB+MDC/

Finally, canceling decrypt/verify should also work properly.

Closing since the problem doesn't seem to occur if the operation is canceled properly.

Sorry about that. I tested an old build which didn't call gpgme_cancel_async and therefore probably didn't properly close the channels. It seems to work if gpgme_cancel_async is called to cancel the operation.

This option is already used. Running pgrep -a gpg in a loop (and ignoring gpg-agent processes) I get:

Mo 26. Jun 11:29:11 CEST 2023
19111 gpgtar --batch --status-fd 60 --gpg-args --no-tty --gpg-args --charset=utf8 --gpg-args --enable-progress-filter --gpg-args --exit-on-status-write-error --gpg-args --display=:0 --gpg-args --ttyname=/dev/pts/37 --gpg-args --ttytype=xterm-256color --decrypt --directory /tmp/kleopatra-JqIiXu/src -- /home/ingo/dev/g10/src.tar.gpg
19112 gpg --batch --status-fd=60 --output - --decrypt --no-tty --charset=utf8 --enable-progress-filter --exit-on-status-write-error --display=:0 --ttyname=/dev/pts/37 --ttytype=xterm-256color -- /home/ingo/dev/g10/src.tar.gpg

Argh:

void DecryptVerifyTask::cancel()
{

Can you please test by adding --exit-on-status-write-error to the gpg invocation by gpgtar?

Strange though, it appears that it is cancelled before finishing the job, no result file is created. But maybe that is when finalize or something would be called in Kleo.

When testing this I noticed that the cancel does not seem to have an effect on normal file jobs run directly through Kleo either: T6560 This is probably not a regression as you fixed here that the cancel is even propagated to the jobs but still I find that disturbing and buggy.

I don't argue about the technical necessity for the change. I agree the fact it works (without such changes).

The proposed new expiration date is now the same as for the generation of new certificates, i.e. today + configured default validity.

I hate this ping-pong, but, as I wrote in my previous comment, for me canceling decryption does work on Windows, i.e. the gpgtar process does not keep running for a long time. That the gpg process keeps running is nothing Kleopatra can do anything about.

I have tested this with a self-built installer from a few minutes ago in my Windows VM. Whenever I canceled decryption (I tried it about 5 times), then the gpgtar process went away very quickly. The gpg process keeps running, but that's a bug in gpgtar: T6558: gpgtar: Does not stop spawned gpg process when exiting.

cancelling decryption does not work yet on windows

Should be fixed.

I don't think this is the right choice: Un Unix we have file descriptors which ar an (int) and on Windows we use (HANDLE) which is a 32 bit integer. See my comment in T6551 regarding values for HANDLE.

Just to clarify this change for readers not accustomed to Windows internals: This function was used to translate the file descriptor as passed to gpg (which is a HANDLE) to the libc file descriptor as used by stdio. Obviously we won't anymore work with stdio file descriptors in the future but use the Windows32 API (ReadFile et al). libc fds 0,1,2 are handled in a special way on Windows.

Fixed in master.

Pushed a change in master.

Applied.

When the output parameter is given it might even clean up a temporary file on error, but it might also not so we should make sure on a higher level that we check for that and remove it when gpgtar crashes or something like that.

Due to the double fork in gpgme we won't get the exit code which gpgtar emits. Possible actions in a signal handler are also limited; in particular we can't use stdio or estream. The only option to print a status line would we by using write directly. However, this might mess with the libassuan buffering. Thus, it is not a good idea to pkill gpgtar. Same is true for gpg and gpgsm.

I'd prefer "Ablauf Hauptschlüssel" as I don't like "Primärschlüssel". But definitely in two words.

See for T6545 for a new request to support IDP.

We had one request to support this back in 2017 but it was closed because the respective CA stopped using this extension. See T2039.

I found the case of X.509, which also uses fixed length output for RSA-PSS and ECDSA: https://www.rfc-editor.org/rfc/rfc8692.html