For the record, we've removed the SRV record for keys.gentoo.org for now, to work around the problem. Without the SRV record, everything works as expected.

I pushed the change which keeps old status report behavior to master.
Let me test the change.

looks simpler to me.

Should be fixed now; see commit above.

FWIW: WriteFile and write are more different than in using a HANDLE vs. a libc file descriptor. Despite that a HANDLE might be a 64 bit pointer, it is guaranteed that the value fits into a 32 bit variable. But they still index different objects. The return code and error values are also different.

Much simpler: write is only used in the callbacks and over there gpgme_io_writen[n] shall be used anyway.

Hmm, for the latter this:

Orthogonally, here is possible change for GnuPG, if we need to support the workaround of compress-level 0 in ~/.gnupg/gpg.conf.

Kleopatra test case (similar to gpg):

OK, here is my changes which always use make-temp-file (to avoid confusion between data input and passphrase input).

I use epg.el with the change of removing the wait:

it's not hard to fix that header to actually provide a sensible write(), avoiding the issue listed on the mailing list, where there was no return to check:

Seems it gets a record but is not able to parse it (gnupg/dirmngr/dns-stuff.c:getsrv-standard) in your setup. Not sure why it loops - need to debug it.

Ok, it seems that my reproducer isn't correct after all. The user just confirmed that the SRV lookup succeeds on their system, so it seems GPG hits some loop repeating that for no apparent reason.

On the command line it works. It seem's to be a problem of Kleopatra.

Can you try on the command line, errors might be more specific there. This can be caused for example by a wrong system clock.

Fixed in 2.4

closing, as setting a password on a key without password works (at least in current gpg4win version). For improvement of the user guidance see T6436.

--openpgp means the current OpenPGP standard as implemented by GnuPG. This was important in the first few years of OpenPGP but not anymore today. The option --rfc4880 might be what you want. Please keep also in mind that the preference list declares what a concrete implementation supports and not necessary what's in an RFC.

works

Thank you, your suggestion inspired me to experiment a bit further and I found the problem - I needed in fact to delete the line from my ssh config, no idea why:

Match host * exec "gpg-connect-agent UPDATESTARTUPTTY /bye"

Now I update startup tty only on terminal start and it seems to be working. Still a bit strange.

This is a standard C pattern to declare that one is not interested in the return value. In this case a return value won't help us because we can't log that anyway because we are in a signal handler.

On a terminal, please invoke:
$ gpg-connect-agent UPDATESTARTUPTTY /bye

You are right, it is a bad habit not to check this. Thanks for your patch.

it would break the verification of too many signatures.

backported to 2.2

works, no KIO error. Gpg4win-4.1.1-beta317

@werner We could make the wait conditional on (equal epg-gpg-program "gpg"), that is, only when user has GnuPG 1.x.

Well okay, then I have no workaround. However, I won't consider this a bug because BEGIN_ENCRYPTION marks the start of the actual encryption process but not when it starts to read input data.

The change rG60963d98cfd8: gpg: Detect already compressed data also when using a pipe. for T6332 introduce IOBUF_IOCTL_PEEK.

@werner I tested by switch back to GnuPG 2.4.1 (I downgraded to 2.4.0 before to temporary work around issue), adding compress-level 0 to gpg.conf file. It's not working. The problem still exist.

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;
                                                }