I located the problem. The test program use-exact-key invokes two gpg-es connecting by pipe (one gpg to generate a signature, another gpg to verify the signature). Those multiple gpg-es race accessing keyboxd.

@werner Please backport to 2.2.

Fixed. Until the lookup is completed, a question mark icon should be shown and no error should be displayed.

Another test, it took 30 minutes to replicate.

I'm afraid we need a bit more information. Please tell us the exact steps how you can reproduce the problem.

catch the newest version
full git formatted patch here: https://fars.ee/LN-i.patch

My Yubikey (Yubico.com Yubikey 4/5 OTP+U2F+CCID) (key Ed25519) works fine with OpenSSH using kex of sntrup761x25519-sha512@openssh.com.

Thank you. I can replicate the issue.

After re-running myself a few times, I managed to hit it again. In tests/openpgp/report.xml, I see:

[...]
<testsuite name="&lt;keyboxd&gt;tests/openpgp/use-exact-key.scm" time="0" package="&lt;keyboxd&gt;tests/openpgp" id="0" timestamp="2022-04-25T16:18:27" hostname="unknown" tests="1" failures="0" errors="0" >
<properties/>
<testcase name="use-exact-key.scm" classname="&lt;keyboxd&gt;tests.openpgp" time="0" >
<failure message="Unknown error." />
</testcase>
<system-out>
Importing public key.
Checking that the most recent, valid signing subkey is used by default
    &gt; 8BC90111 3E880CFF F5F77B83 45117079 1EA97479 &lt;
Checking that we can select a specific signing key
    &gt; 8BC90111 F5F77B83 1EA97479 &lt;
</system-out>
<system-err>
</system-err>
[...]

Was fixed in 2.3.5

In D435#3175, @dkg wrote:

aiui, the point here is to have the user "service" get triggered somehow (through pam's pam_systemd.so's session module?) before ssh goes ahead and forms the socket. is that right? If the pre-launch mechanism is pam, is there a reason to do it as a systemd user service? That won't work for systems that have pam but don't have systemd, whereas a pam module that creates these will work.

is there any update ? I having the same Issue here on Windows 11 Pro, Outlook Version 2203 (Microsoft 365) 64bit

Any idea? Any update?

Works together with the changes for T5939: Kleopatra: Better error for wrong password in symmetric decryption. Tested with symmetric encrypted file and with symmetric+pk encrypted file.

Thanks. Will go into 2.3.6

Please contact the Debian developers for any systemd/gnupg issues. We don't suggest the use of the --supervised option because it causes more problems than it claims to solve.

I pushed the change above. I also pushed another change with IOBUF_INPUT_TEMP.

In this case it works, because the error messages are not translatable.

Sorry, I was confused. For RSA-4096, data is hashed by gpg-agent and hashed data is signed by a card.

In T5939#157259, @werner wrote:

You should not use log messages because they are subject to change and they are translated. Let us return an ERROR status instead.

We are using rsa-4096 on smartcard for quite some time; so I wonder what's the problem here. Is that that we don't use our Assuan hack for large key material with OpenPGP.3?

There is another case: RSA-4096 key. scdaemon rejects data by Invalid value. Unfortunately, there is no fix for this, as it's really too large. Even if scdaemon allows larger data, the card implementation rejects, when it conforms to PKCS #1 standard (data should not be larger than 40% of the modulus).

Thank you for the bug report.