GpgOL/Web is likely also affected.

Applied to master to be release with 2.5.19.

Apparently, DISPLAY is hostname:displaynumber.screennumber where hostname and .screennumber are optional and where hostname is a hostname or maybe host/unix. Does hostname include IPv6 address literals? Anyway, I guess the only sensible heuristic is to consider any DISPLAY value that contains : as valid.

How is "invalid DISPLAY" defined? DISPLAY=invalid? Anything that's not DISPLAY=:<some number>? Why do screen and tmux have to use an extra-wurst?

In T8156#216401, @ikloecker wrote:

I'm not sure if we should consider env DISPLAY=invalid pinentry-qt a valid test.

[...]

So, I guess, @ametzler1's suggestion to remove the check for isX11SessionType is the correct solution. DISPLAY=invalid would still not work, but I think that's acceptable.

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.

Can you please test the patch below in your environment. That would be helpful.

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

As noted by @ametzler1 pinentry-qt has such a fallback. Of course, we can try to improve the heuristics pinentry-qt uses.

Note: The invalid revocation certificate: Bad signature - rejected line is also shown on vsd 3.3.4, gpg 2.2.53 @ win10 (but revocation works).

feedback of @mmontkowski needed

I think locate mode is mostly meant to be used to retrieve a single key

We talked about this in our developer meeting on Monday. I have never experienced the problem because I use the Qt version only on Windows and for my own use I use the Gtk version. In any case I think that Qt and fltk should fallback to curses to cover the case of using the Pinentry for a system startup on the console (e.g. the g13 case) with later switching to a GUI. And of course for those users who switch between GUI and console.

I applied the keyboxd part for SETEPHEMERAL command, as it doesn't break anything.

With signing only, the retry option is not offered and directly either hangs or shows the "Invalid CRL object" / "Unknown error" error.
Is this intentional?

Here is an attempt to fix the client side:

Pushed: rG8b6de59ad880: agent: Raise GPG_ERR_BAD_SECKEY when p >= q for RSA key.

I have added the fix as patch for VSD 3.3 because the commits that introduced this regression were also added as patches for VSD 3.3.

This is a regression that was introduced with T7759: Kleopatra: Notepad encryption with S/MIME fails.

Fixed. For VSD 3.4 this will also be fixed if gpgme is updated.

This is a bug in gpgme. gpgsm_assuan_simple_command only reads a single line before waiting for more data although there is a second line (ERR ...) ready to be read. gpgsm never sends more data because it has already sent its full answer. So gpgme waits forever.

Note that KWatchGnuPG isn't available on Windows.

Fixed. KWatchGnuPG doesn't modify GnuPG config files anymore. Instead one has to set socket:// as log file for the components one wants to see in KWatchGnuPG.

Pushed the change: rG533bcc265e9c: common:dotlock: Clean up for error/info/warning message.

While I pushed the change of libgcrypt, I'd like to apply following change to GnuPG.
This is more kind than GPG_ERR_BAD_PASSPHRASE by gcry_pk_testkey failure.

I retract my patch in T8171#215603

@m.eik gave us this link: https://github.com/ProtonMail/go-crypto/issues/184

To clarify, the state in Kleopatra Ingo described a year ago has changed, with T7579: Kleopatra: improve menu items the refresh option in the Tools menu was removed. Both actions to update certificates - in the context menu and in the details - are/work the same.

Removing kleopatra tag since Kleopatra already does what's requested.

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?

Well okay. What we could do is to add a --compliance-flag like we have for other components. This is not part of the stable API but it can be used if need arises.

Pushed the last change: rG2239f687bb14: scd:openpgp: UI improvement for use of PIN-entry.

Setting to low because this has never been a problem in the last 30 or 35 years. A check to help pinpointing bad keys is however a good idea.

Backported for VSD 3.4

Should be backported to VSD 3.4 because these changes amend T7212: Problems with certificate colors / styles.

Backported for VSD 3.4

The remaining open points of this ticket will be "won't fix" for now. When we plan to change something here, we should open new tickets, this one got confusing.

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)

Just a quick note: For any operation that imports something I would expect an import result (gpgme_import_result_t) listing the keys that were imported. op_keylist in locate mode is a strange duck because it can list and import at the same time.

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

This is a bit larger change (of UI improvement):

@werner My intention of rG268e435 is removing the need of --directory~ option, in our code.
With this change, we can focus on the behavior of --directory= option.

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

I guess no. But yes, am also annoyed by the default for "insert card" - sometimes several times a day. We should really fix that. See new task T8182

Does this relate to which button is selected by default by a pinentry prompt for inserting a card? I am very annoyed by the default for it being "Cancel" as I can't just press enter after inserting the card, but have to tab to or use the mouse to press the OK button.
It would be great if the default for the card insertion prompt would be OK.
My request is for pinentry on Linux, so the task that was merged with this one is more applicable (that one was for pinentry-gtk2 on Linux, this one is for gpg4win), but that task was closed, so I am commenting on the one still open. Perhaps the task and its title should be edited to apply to all platforms, regarding the default selected button in a pinentry prompt.

I still don't think that --directory~ is a good name for an option. It looks to similar to the ~USER shell pattern. What about --unsafe-directory which also avoids an option ambiguity regression on the CLI?

I located the place where tests/ requires the feature of gpgtar overriding existing files.
I fixed that in: rG268e435f921a: tests:openpgp: With gpgtar, extract tarball into an empty directory.