Fri, Jul 10
Looks good to me on gpg4win-5.1.0-beta658 @ win11.
Thu, Jul 2
Sorry again for wrong short description of the commit message. The commit of rPd63023151d25: Support confirm_focus in pinentry-qt/qt4/qt5/tqt. is for Windows.
Wed, Jul 1
Released with pinentry 1.3.3
For GNOME3, it looks like we have no way to specify focusing "Cancel": https://gnome.pages.gitlab.gnome.org/gcr/gcr-3/iface.Prompt.html
Done for: Curses and GTK+2
(My commit message for GTK+2 change was wrongly described as curses, though. sorry)
Tue, Jun 30
Jun 3 2026
May 22 2026
I'm not sure what is meant by this. Needs to be clarified.
May 20 2026
Apr 29 2026
Apr 16 2026
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.
Apr 15 2026
gnupg22 received this patch meanwhile: rG7bc969d388086b4f3aeee3c5389b7baf055689d7
Apr 1 2026
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:
Mar 31 2026
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
Mar 23 2026
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?
Mar 19 2026
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.)
Mar 18 2026
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
Mar 3 2026
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
Feb 27 2026
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.
