Tue, May 10
Thank you, @gniibe. That's what I was missing: installing libsqlite3-dev made the difference.
Pushed the fix.
You need to install a package like sqlite-devel or libsqlite3-dev, so that you can have development header files and library (sqlite3*.h and libsqite3.so) and pkgconfig file (pkgconfig/sqlite3.pc).
Yes, I saw that in the logs and installed those packages. Now I have sqlite and sqlite3 in /usr/bin, but that doesn't seem to have changed anything.
the link's target doesn't exist
Mon, May 9
Yes, of course I did that. The error output I included followed the sequence
Please do make at first before invoking make check. It creates symbolic links for executables.
Fri, May 6
Thu, May 5
When we implemented this first, Libgcrypt had no appropriate KDF support. I recall that I considered to change this but it turned out the for 2.2 the changes are too large. For 2.3 we will consider such a change.
Tue, May 3
Fixed in GnuPG 2.3.5.
Nitrokey Start uses Gnuk as its firmware. You need to upgrade its firmware to version 1.2.16 or newer.
Please note that when upgrading the firmware, your keys will be removed.
Mon, May 2
Its a nitrokey start. I gave it another spin just to make sure, and again when updating to openssh 9.0 and "gpg (GnuPG) 2.3.6-unknown", it fails (again with careful gpgconf --kill gpg-agent etc. Double checked the downloaded source code by arch's makepkg, appears to have that patch applied. Also tried adding -o KexAlgorithmsfirstname.lastname@example.org to the ssh command, which didn't help.
Please describe what token is used. For my use cases with rGe8fb8e2b3e66: scd: Don't inhibit SSH authentication for larger data if it can., both of Gnuk (>= 1.2.16) and Yubikey (>= 5) work well.
Fri, Apr 29
I'm seeing something just like this when attempting to install gnupg-2.3.6 on Ubuntu 22.04 LTS (running under WSL 2, if it matters).
Thu, Apr 28
FYI, I built 2.3.6 using a modified archlinux PKGBUILD (& disabling patches to avoid conflicts), then did:
gpgconf --kill gpg-agent
gpgconf --launch gpg-agent
but ssh still fails as before
Wed, Apr 27
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.
Tue, Apr 26
@werner Please backport to 2.2.
Another test, it took 30 minutes to replicate.
My Yubikey (Yubico.com Yubikey 4/5 OTP+U2F+CCID) works fine with OpenSSH using kex of email@example.com.
Thank you. I can replicate the issue.
Mon, Apr 25
I pushed the change above. I also pushed another change with IOBUF_INPUT_TEMP.
Sorry, I was confused. For RSA-4096, data is hashed by gpg-agent and hashed data is signed by a card.
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.
Fri, Apr 22
Should also go into 2.2
The rest of the code looks fine.