No, there are use cases in GnuPG, where we specify the hash algo for signing, and our own tests/benchmark.c.

For the first issue, I added a check in: rCf65c30d470f5: cipher:ecc:fips: Reject use of SHAKE when it's ECDSA with RFC6979.

This has long been fixed in 2.4. Given that Libgcrypt has support for PBKDF2 we can back port this.

From the FIPS 186-5 there are some limitations to use the SHAKE in FIPS Mode that we will have to reflect:

We need to keep the gpgtar part of commit in rG2756147e392c: gpg,sm,tools: Use string for option --*-fd..

The changes are intrusive to other implementations (POSIX and Windows 32-bit).
So, I revert the changes of replacing translate_sys2libc_fd_int.

This no longer happens. It was a case of such inline signature images. Maybe if they are added through the clipboard they dont get a filename or something like that.

I do not agree that this will help much, but I am all for changing the string "Find more info on Wikipedia" into something like "See the Quickguide for a short introduction".

I give it the same prio as the parent task

Yes, this should be a fairly low hanging fruit and would improve UX for some users probably quite a bit. So while not very important I give it high priority because we should do it sooner.

I would give this normal priority still. In guess in most cases its not an issue but when it is an issue it will feel like a bug.

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.