I have not yet experienced that although I am using Gnus with encrypted mail all the time. My guess is that this is due to the improved compressed input detection in gpg. You might be able to work around it by adding compress-level 0 to gpg.conf

To sort out LTO warning someone needs to make the decision which one routines declarations are correct (those in header files or those in .c files).

As I mention LTO warnings are most important.
Just retested 2.4.1 and I still see LTO warnings which still not been sorted out and those warnings are not false positives.

[tkloczko@pers-jacek build]$ rpmbuild -ba --with check --with failing_tests gnupg2.spec --quiet 2>&1 | grep -- \\[-W | sed 's/.*\[//; s/\]//' | sort | uniq -c | sort -nr
     28 -Wunused-result
     22 -Wlto-type-mismatch
      4 -Wenum-int-mismatch

<details>

Just checked 2.4.1 and looks like now everything is OK.

Starting to understand KIO architecture a bit better. We can easily add more protocols if we want to. For now I have just added the file plugin. I tested with moving.

I don't see a reason backing off the original commit. A fix for macOS is now available (rCfa21ddc158b5) and will be in the next release. No reason for other changes.

Thank you for your report. Good catch.

The fix is in 2.4.1.
It's not perfect fix, but it catches the problem when it's not encrypted secret key.

The code for the file Job etc. is definetly in there. I think it somehow tries to intospect supported protocols maybe even through dbus and this fails then. My current expectation is that we need to identify where this happens and then to hardcode some supported jobs / workers etc.

Yes most definetly I am looking it at next

Setting priority to high because this should be fixed before the next release.

works now, Gpg4win-4.1.1-beta295

works

works with Gpg4win-4.1.1-beta295

Fixed for libgcrypt, updating copyright notices and license files.

File dialog and notepad now share the last used signature and encryption to self key. Works.

Here's fix for mode specific setkey clearing error code:

There is still a buglet because in some modes the weak key error can be swallowed by other errors. A fix would be something like:

@jukivili Yes, please go ahead for both branches. Thank you.

I checked the upstream. For the reported issue, upstream version raises an error with REG_ERR_UNMATCHED_BRACKET.
That behavior is better (as we don't have particular reason to maintain different behavior from upstream version).
Also, I found another change from upstream for end of word check.

About error code. You need to use gcry_err_code(error_code) to get the GPG_ERR_WEAK_KEY value.

Okay, that was easy to check.

The options for key backup+delete, delete and keep all work now, tested with VS-Desktop-3.1.27.0-beta44

To test this you need to create an OpenPGP key without signing capability.

@gniibe, will you be so kind an check the provided patches

To replicate the problem it is best to use Windows. Should be solved with my commit. Note that the bug is specific to 2.4 dues to irts multi-card and app support. There was no problem on 2.2.

gpg --edit-key; keytocard; save

work as expected.

Another miscellaneous correction for jimregexp. A condition was copy-pasted from another section without the necessary changes, resulting in incorrect logic. This seems harmless apart from inconsistent error reporting.

diff --git a/regexp/jimregexp.c b/regexp/jimregexp.c
index 1a8b8aae6..1b6e1b49c 100644
--- a/regexp/jimregexp.c
+++ b/regexp/jimregexp.c
@@ -778,7 +778,7 @@ static int regatom(regex_t *preg, int *flagp)
                                                        preg->err = REG_ERR_NULL_CHAR;
                                                        return 0;
                                                }
-                                               if (start == '\\' && *pattern == 0) {
+                                               if (end == '\\' && *pattern == 0) {
                                                        preg->err = REG_ERR_INVALID_ESCAPE;
                                                        return 0;
                                                }

The actual error is in gpgme. CreateProcess is called with "gpgtar" but "gpgtar.exe" must be used.
This has been fixed with commit rM0c29119e061c. The reason why we didn't noticed the real cause of the problem is that the CreateProcess error shows up in the gpgme-w32spawn helper which has no good way for returning errors.

As far as I understand the problem, all content-ids are lost during processing of an email.
This process happens during the signing/encryption of an email.

Ok sorry, my bad, I have to use DES Keying option 2 to have 45 de ae ae e1 f4 6a 29, problem solved.

In T6451#169608, @gniibe wrote:

Reading the commit rC5beadf201312: Add gcry_cipher_ctl command to allow weak keys in testing use-cases,
The test code in basic.c assumes that it is an application responsibility to confirm&ignore GPG_ERR_WEAK_KEY error when using GCRYCTL_SET_ALLOW_WEAK_KEY.

Thank you for you responses! :)

I'll add documentation about GCRYCTL_SET_ALLOW_WEAK_KEY which was missing from be original commit.

tests/basic now actually fail because setkey not returning GPG_ERR_WEAK_KEY for weak keys with GCRYCTL_SET_ALLOW_WEAK_KEY.

That's right. With GCRYCTL_SET_ALLOW_WEAK_KEY, setkey still returns GPG_ERR_WEAK_KEY when weak key is detected. However, cipher handle can still be used as if setkey succeeded.

Reading the commit rC5beadf201312: Add gcry_cipher_ctl command to allow weak keys in testing use-cases,
The test code in basic.c assumes that it is an application responsibility to confirm&ignore GPG_ERR_WEAK_KEY error when using GCRYCTL_SET_ALLOW_WEAK_KEY.

Thanks for the report. Fix is easy. I only wonder why you want to use a weak DES key.

works

isn't T3456 the same issue?

my Yubikey works, too, if I disable PIV. With enabled PIV:

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.19.0.

Fixed in 1.19.0.

This problem was introduced by commit cf10c74bd9d5aa80798f1c0e23a9126f381b26b3. Perhaps that change should be backed out in the interim so that a portable fix can be considered for the original issue?

Unfortunately I can't replicate that with my Yubikey on 2.4.1. Tried several variant and with and without keyboxd. My Yubikey has PIV disabled but I doubt that this is the problem.

Test with GnuPG 2.4.1-beta76 failed with "error getting current key info: invalid name":

It is a bit complicated. Let me describe the situation.