[...]
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.
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 to 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:
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?
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):
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.
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.
I sent a patch to gcrypt-devel mailing list for the preparation of the change of RSA secret key checking.
If enabled, wrong RSA secret key (wrong means: under the Libre/OpenPGP specification) is rejected at import when gpg-agent calls gcry_pk_test_key.
BTW, LibrePGP also demands p < q in "Algorithm-Specific Part for RSA Keys".
added vsd34 for the resetting of the defaults
I investigated the introduction of STATUS_CANCELED_BY_USER and GPGME_STATUS_CANCELED_BY_USER:
rG31e47dfad0f4: gpg: Add canceled status message.
rM35ca460019ea: Parse STATUS_CANCELED_BY_USER.
For OpenSSH, ssh-agent spec. defines p, q, and qInv.
FIPS has: FIPS 186-5 and SP 800-56Br2.
existing standards
Filter 16 is the new filter for valid certificates. The problem could be that the version you tested did not yet have this filter.
CRT is used with GnuPG. In libgcrypt, pk_sign and pk_decrypt don't require P, Q, and U in a key (it's optional), but pk_test_key does.