I think that's a known issue (or a known non-issue). I ran into this some time ago and therefore added the possibility to start gpg-agent explicitly instead of relying on a keylisting to start the agent implicitly. My guess is that gpg doesn't start gpg-agent because if there are no public keys then it makes little sense to ask gpg-agent for private keys.

just noticed that restarting the background processes with F5 on the certificate list does not work if the list is empty. (checked with Gpg4win-4.2.0-beta357)

closing this due to external testing. The follow up on this is T6568

This works in so far that the background processes are killed with the restart button. For remaining issue see T6567

works

works

Except a case, all use cases of translate_sys2libc_fd_int is with a result of integer from command line argument.

Partly done for 2.4. The cram-octet-string stuff is missing, though.

This will not translate into the new addon and is too large a change for the current one.

Thanks for the suggested workaround, I am going to try that. And thanks for pointing out this could be related to something like a Yubikey attached. Having the same symptoms as those described in T4581 and here.

I have this regularly. Sometimes waiting helps and it loads after several minutes, sometimes shutting down Kleopatra is the only remedy (because after an hour and more it feels like it ended up in an infinite loop).

Add the check of digest algorithm for EdDSA in: rCd15fe6aac10b: cipher:ecc:fips: Only allow defined digest algo for EdDSA.

Changes are pushed.

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