Fixed in master and 1.10 branch.

No, it would break the verification of too many signatures.

Probably, this change should work:

diff --git a/po/zh_CN/kleopatra.po b/po/zh_CN/kleopatra.po
index 56b06e04..f34112a9 100644
--- a/po/zh_CN/kleopatra.po
+++ b/po/zh_CN/kleopatra.po
@@ -4680,7 +4680,7 @@ msgstr "发件人"
 #: src/crypto/gui/resultitemwidget.cpp:132
 #, kde-format
 msgid "Force decryption"
-msgstr "强制加密"
+msgstr "强制解密"

After testing the builds of master for several distributions/gcc/clang, applied to 1.10 branch too.

closed, as the remaining subtask is found at T6436

On gpg4win 4.1.0 (and GnuPG VSD 3.1.26) there are no longer password prompts for the subkeys when exporting (or making a backup from) secret keys.

Your quick support solve my problem, I am thanking you :)
Bye bye

I added a remark to the print function. Thanks for the suggestion.

You are right, w.y should be "00039E2C9AEC146C5799651C42691A3E35E291B6BC45FF079DDA3E70E709BF33".

Can you please share the expected result with us? Note that Libgcrypt strips leading zeroes except when it is required to keep the value positive.

if your'e asking me, i'd suggest just let it be fixed going forward unless someone else complains

Thank you for the report.
Fixed in master. Let us consider if it will be backported to 1.10 (or not).

works in 3.1.27.0-beta44

This has been solved loooong ago.

Actually this is about improving an error message.

@tlaurion Thank you for the report, but your particular problem is irrelevant to this ticket.
I lightly looked the log and noticed that the cross build would have some confusions for pkg-config, however, that's not our problem but yours.
For the particular failures in your build, the issues look like a problem of musl linker. It seems that it requires all dependency of libraries to be used, even if an executable doesn't use a library directly.
If it is the case, we need a patch... something like:

@gniibe
Trying to crosscompile newer 2.4 gpg toolstack from Heads OSF under PR https://github.com/osresearch/heads/pull/1350

Fixed in master (of libgpg-error).
Pushed the change to libgcrypt (master and 1.10 branch).

works in gnupg24.

I'd say yes.

Thank you for the bug report.

@gniibe: Would you mind to look at this?

README and INSTALL now suggest to to use a build directory.

Error checking of the parameter file is usually enhanced when adding new features. Keeping this task open for this specific request does not make sense,

Fixed.

FYI: Quite some more days than a few passed by. I still did not found the time for this, sorry.

Hi @werner,
I understand we should use --with-libksba-prefix, but it doesn't work:

That is not a bug but required for backward compatibility. See me/ksba.m4:

Hint: When the user disabled GpgOL -> Automation -> Automatically secure messages in the configuration of GpgOL he could see the email body again.

This isn't a support forum. You'd better ask on the gnupg-users mailing list before assuming that you found a bug.

Closing this one - see T6378

Fixed in 2.2 need to check 2.4

Ooops. We do not have the automatic chnage of key type in the WRITEKEY command of scdaemon. This is only done when generating a key.

There is actually a regression wit Yubikeys. The fix for 2.2 is in T5100: rG08cc34911470 - for 2.4 I need to check

I agree. Something called READ... shouldn't change existing data. (Updating existing data to a new format that doesn't alter the semantics of the existing data is okay.)

Ignoring the error seems to be the best choice. I also think that --force should not overwrite a shadow key file. It seems safer to explicitly delete the key first. A --force option for READKEY does not sound right.

I did some reworking and the outcome of the READKEY command is now (agent log):

I checked it: There was an empty bin/gpgconf.ctl, and there still is.
Trying it again today, I still get error messages most notably about failed self-tests, but surprisingly the window is no longer empty.
Instead it seems to take an eternity (minutes, actually still not finished after three minutes) until the certificate cache is loaded.
Maybe the problem is the "Check Point Endpoint Security" being active on the client. It looks as if it prevents use of Kleopatra.
As I don't have administrator rights ("for security reasons"), I cannot analyze what's actually going on.

It seems that you are missing the step "Create a new file called gpgconf.ctl in the folder Gpg4win_Portable/bin."

I am pretty sure we have the same problem in 2.4 - due to different access patterns it might not exhibit itself.

I've run into a variant of this, too. If I generate they key just using (genkey (ecc (curve "Ed25519"))), it is recognized as an encryption key. One needs to use (genkey (ecc (curve "Ed25519")(flags eddsa))).

Its not used, so it can't harm.

Also recall that Antivirus software needs to search for a competitive advantage over other vendors and in particular over Windows Defender. Thus they need to show some extra positives compared to the Windows Defender. Who care whether this is a false positive - ppl like to get some evidence that their new AV software has a (phoney) advantage.

Many thanks for the information. I suspected it also, but wanted your assessment.

Well, virus checkers aren't perfect. If 1 out of 65 checkers reports a finding, then the probability that this finding is a false positive is very high. You would better report this to the vendor of NANO-Antivirus, so that they can fix the false positive warning.

Applied your patch (from gitlab) to both (master and 1.10).

Applied to both (1.10 and master).

You are right, there is no way to use DRBG with SHA384 by libgcrypt.

Applied to both (1.10 and master).

Applied to both (of 1.10 and master).

Thank you!

Looks like the TERM alacritty was the culprit, I'm ssh'ing into the freebsd machine from my archlinux laptop.