This has a serious usability issue. If you cancel the password entry when exporting it reports success and creates an apparently valid secret key file but without the subkey you intended to export. So worst case the user thinks he has a backup but instead has no backup :/

with the new gpg.exe you gave me for testing it looks good now:

related to T6528

No. Missing mapping in iobuf.

But yeah, General Error is never good :)

For what its worth, GnuPG keeps the timeout value this way for some reason with server usecases if I remember correctly so that other keys are tried when one times out. In GnuPG VS-Desktop we configured a 10 Minute timeout as a compromise.

gpgrt version?

I get a failure status, but a different one.
Seems to be an other issue? But wasn't (ec=112) disk full?
And the disk of the Windows VM must have been running full with that file, before the start there were ~2,6 GB free:

Followup on this is: T6574

I noticed this recently, too. Should be fixed. Especially if we want to use this in KMail, too.

I changed the title accordingly. I think when we call the option "restart background processes" we should not implicitly rely on a non empty keylist to start the gpg-agent but instead trigger it explicitly

I think the priority is low because the optional columns are not really that useful for most users and were mostly added as a "nice to have" feature. The details are in doubt available e.g. through the certificatedetails widget.

works as described

This works.

OK. I'll take the signing part (possible performance improvement).

No, it doesn't do even that. Sorry, I only tested that with 3.1.26 which is older than your fix.
No encrypt-only key is offered or selectable for signing any more in Gpg4win-4.2.0-beta360

I looked through the code. What I observed is:

• By jussi's improvements, AEAD code is optimized with AEAD_ENC_BUFFER_SIZE of 64KiB
  • this contributes much for better performance
• If we invoke gpg --sign | gpg --encrypt then we can take advantage of multiple CPUs (but gpg is currently not automatically threaded in that way)
  • signing could be improved likewise, using larger buffer like 64KiB
• CFB+MDC, it uses two functions together; encryption and hashing, and not with larger buffer like 64KiB
  • when signed, it also does hashing for signing, so three functions

The case in check_special_filename is fixed. So, there is no cases in GnuPG where the value of out of range is silently converted to wrong value.

Remaining places are:

• common/sysutil.c debug output to format HANDLE --> T6597
• common/sysutil.c iobuf_get_fd and its use cases --> T6580
• agent, kbx, scdaemon, dirmngr: socket and FD2INT/INT2FD --> T6598

I don't think that Kleopatra allows to select an encrypt-only key for signing because I have fixed exactly this issue a couple of months: T6456: Kleopatra: Offers encryption-only OpenPGP keys as signing key.

This works, when sign is selected and no standard OpenPGP key for the mail address exists.

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.