I have set T6513: Kleopatra: Require GpgME 1.21 as blocker for this issue because, in my opinion, showing the above mentioned "Operation fully cancelled" error message is from a user perspective worse than showing multiple password prompts.

Fixed.

They re-used the same file name for the update from March and no history section. Anyway that looks promising and may solve the problem of having different algorithms allowed for restricted communication in the EU and the US.

Correct, but the last revision of FIPS 140-3 lists the EdDSA already. The same for the IG for FIPS 140-3:

My understanding is that FIPS 186-x lists more algorithms than approved for FIPS 140-y; the approved algorithms for 140-y are in the latest revisions of SP800-140. I have not checked the latter document, though.

See also commit rG6fcc263c18 from 2020 where I switched to D-lines.

The problem of hang of tests/openpgp/multisig.scm is solved by rGef4f22b9d98b: gpg: Graceful exit for signature checking with --batch.
But the problem itself is not yet solved.

It is reproducible by testing tests/openpgp/multisig.scm with keyboxd enabled (it hangs), with the modification of following.

The following works, too:

Setting close_button when the user rejected the pin entry (by pressing the close button, the Cancel button or Esc) causes fully canceled. Unfortunately, Kleopatra (and in fact GpgME::Error) has no idea that fully canceled should be treated as canceled and not as error. Therefore, Kleopatra shows an ugly error message:

An error occurred while trying to change the passphrase for [...]:
Operation fully cancelled

The output folder is now checked with enabled NTFS permissions check for writability. Hopefully, this fixes the problem on Windows.

Kleopatra explicitly checks if the output folder is writable using QFileInfo::isWritable. But: QFileInfo::isWritable mentions that NTFS permissions are not checked unless this is enabled explicitly (because it's an expensive operation). I'll try to enable it locally for the check.

On Windows, we had to revert to the old approach which doesn't show progress because KIO::move doesn't work on Windows when crossing partition boundaries. We want to fix this in KIO for a future release. Windows users will have to live without progress for now.

Fixed as suggested by Andre. Additionally, I have added support for hidden files in the old code (which are probably not really a thing on Windows). The downside is that there is no progress on Windows (as before the switch to using KIO::move).

Let's schedule that for 2.6

Possibly, it may consider the case where errno==0 when failure.

Hmm, gcc used to figure out that attr is initialized by npth_mutexattr_init. One of these gcc warning regressions?

Fix merged to release/23.04 branch.

And thanks gniibe! I have tested 2.4.1 several times in this month (including existing and new keys), the warning was never shown again.

Hi zhangguangzhi, I think that it's version-specific problem.
I traced the chain and this warning message was added in release 2.3.3 T5565.
The problem should be able to reproduce between 2.3.3 and 2.4.0.

Hi，i try to reproduce the problem, my platform is linux and gnupg2-2.2.32-3, but i can't find “gpg: warning: lower 3 bits of the secret key are not cleared". Excuse me, is this a platform-specific or version-specific problem, or is it my operation wrong.