I reworked the reading using our dedicated line reading functions which is used at other places. Extra benefit is that the code now also prints a status line ERROR which gives information on the first faulty line. Thus gpg-connect-agent listtrusted /bye can be sued to quickly check for errors without configuring a log file.

gnupg22 received this patch meanwhile: rG7bc969d388086b4f3aeee3c5389b7baf055689d7

Great spotting! This was it. Quite embarrassing that I've looked at this code so many time yet it didn't cross my mind to double check arguments order.

@jpalus You are right.

computed by ssh_signature_encoder_rsa, including additional 0, reach:

Note that exactly same data and length computed by ssh_signature_encoder_rsa, including additional 0, reach:
https://github.com/openssh/openssh-portable/blob/V_10_2_P1/sshkey.c#L517-L537

Let's see whether Niibe-san still remembers the T7882 case.

Added some debug logging and whenever login issue occurs new logic is applied:
https://github.com/gpg/gnupg/blob/bc7c91bee521e4adf3506ca32bf34177b84ce1c5/agent/command-ssh.c#L1482

Looks like indeed related to T7882. After reverting c7e0ec12609b401ea81c4851522d86eb5ec27170 I was able to make 2000 connections without any issue. Bringing the change back and retrying issue appeared within first 300.

I've already tried with verbose which gave no errors. That's why I moved to debug logging. With double verbose I don't see anything wrong either. Excerpt from log for relevant 100 connections among which 1 failed:

$ cat gpg.log | 
    sed 's/.*gpg-agent\[[0-9]*\] //'  | # remove date, time and process id                            
    grep -v 'ssh handler .* \(started\|terminated\)' | # appears to be mostly noise wit hex address
    sort|uniq -c
     80 new connection to /usr/libexec/gnupg2/scdaemon daemon established
     20 new connection to /usr/libexec/gnupg2/scdaemon daemon established (reusing)
    100 received ssh request of length 1
    100 received ssh request of length 208
    100 received ssh request of length 748
    100 sending ssh response of length 1
    100 sending ssh response of length 281
    100 sending ssh response of length 626
    100 ssh request handler for extension (27) ready
    100 ssh request handler for extension (27) started
    100 ssh request handler for request_identities (11) ready
    100 ssh request handler for request_identities (11) started
    100 ssh request handler for sign_request (13) ready
    100 ssh request handler for sign_request (13) started
    100 ssh-agent extension 'session-bind@openssh.com' not supported
    100 ssh-agent extension 'session-bind@openssh.com' received

You need to get a log form gpg-agent. Put this into ~/.gnupg/gpg-agent/conf

But the original patch rG1b4ac98de7db: agent: Accept a trustlist with a missing LF at the end. was not working to allow missing newlines in gpg4win-5.0.0 @ win11?

That change is too complex for just getting a proper error message. The original patch covers the most common case.

This should also be fixed in 2.2 and 2.4 (if neccessary)

It seems that pinentry-curses defaults to "OK".
(my branch for GTK-4, same.)

Cancel (in pinentry-qt) was made default with rP291089ed476d75c71ef1984a7c081d27e357437d. Marc's ChangeLog entry was

• qt4/main.cpp: (qt_cmd_handler) make Cancel the default button for CONFIRM

Looks good to me on gpg4win-5.0.2-beta2 @ win11:

• first manual gpg -K and gpgsm -K displays the correct output now
• the loop ran without a hang for 50 times

I found that it's not that simple to accept the case of no newline at the end.
Because we need to handle the edge case where no newline occurs at the maximum buffer length, too.
It's something like the following.

I found two issues in libgpg-error for spawning functions.

Oh yeah, the mentioned patch is bogus because it assumes that fgets has already set the eof flag while reading the last line. This seems not to be the case.

I added the gpgsm log output in the description (same error as in the gpg log)

To reproduce the hang, a loop will suffice (usually happens within the first 15 times, once it needed 50 runs):

I have this fix committed to my working directory:

We have no CVE yet. However, CVE is also a good tag for security bugs,

On 2026-01-20, I found the message to security@gnupg.org of:
Message-ID: 4e708880-04ac-45bc-8d16-6b585f2652a1n@aisle.com
in may spam folder. It has a 10MB long attachment. That might be one of reasons to be identified as a spam.

This does not happen any more, tested with Gpg4win-5.0.0-beta479

fix tested and confirmed with GnuPG 2.5.12 on windows 10

i've included logfiles for gpg-agent and scdaemon with debug-level 10. the files include

We will do a new gpg4win beta soon.

@m.eik Could you please enable debug option for gpg-agent and get the log output for the crash?

This was release with 2.5.7.

Thanks, that was the only issue building there.

Please re-open if you find other Cygwin related build problems.

You know that Cygwin is not supported but if that is the only place it should not arm to fix it.

(2) Update the documentation of default-cache-ttl zero value disabling caching.

I am going to do:
(1) Recover old behavior with max-cache-ttl = 0
(2) Update the documentation of default-cache-ttl zero value disabling caching.

I can't see any documentation that a value of 0 disables the cache. The user might have used some undefined behaviour. For example in the old code we did a housecleaning when we were idle but the new code uses a timer and another thread for flushing the cache. We could open a feature request to entire disable the cache but I bet that we will get a lot of new bug reports because users will then need to enter their passphrase too often for one operation.

It's not my intention. I didn't know the feature of disabling caching by max-cache-ttl to 0.
Well, it's a regression if a user intends so.

Lucas Mülling commented yesterday on gnupg-devel:

Here we go:

Alright, my above putenv option won't work because it modifies the session environment and thus needs to be run for each gpg-agent session (connection). Adding a putenv_startrup option would help here but this way each connection could chnage the environment - also not good. In the end a way to modify the used environment variables, as you suggested, is a better way.

Yes, the workaround is to use a pinentry wrapper script that sets the value back to the correct one and then invokes the real pinentry.

Got a simple fix for this which does two things:

1. Correctly act upon an error from the backup file writing
2. Print a warning note.