From vagrant at debian.org  Mon Apr 11 23:18:11 2022
From: vagrant at debian.org (Vagrant Cascadian)
Date: Mon, 11 Apr 2022 14:18:11 -0700
Subject: Bug#1008573: gpg-agent -managed SSH keys stored in Yubikeys
 cannot be used with OpenSSH 8.9
In-Reply-To: <875ynfqz3c.fsf@contorta>
References: <5e2d865f-96fa-4455-b3f5-6cceb147f4ea@www.fastmail.com>
 <5e2d865f-96fa-4455-b3f5-6cceb147f4ea@www.fastmail.com>
 <875ynfqz3c.fsf@contorta>
Message-ID: <87y20bpbe4.fsf@contorta>

On 2022-04-11, Vagrant Cascadian wrote:
> On 2022-03-28, Philippe Gr?goire wrote:
>> After upgrading openssh-client to 8.9p1, Yubikey-managed SSH keys
>> can no longer be used. After downgrading to 1:8.4p1-5, it works.
>> I believe this is due to recent changes in OpenSSH 8.9 regarding
>> ssh-agent communication protocol which GnuPG hasn't yet picked up,
>> but haven't found anything on GnuPG's bug tracker.
>
>> $ ssh example.com
>> sign_and_send_pubkey: signing failed for ED25519 "cardno:XXXXXXXX" from agent: agent refused operation
>> username at example.com's password:
>
> Same problem with Gnuk, presumably multiple or all smartcards are
> affected?

According to some folks on irc.oftc.net #debian-devel, not all
smartcards are affected, we're the lucky ones!

I am using a fairly old build of gnuk, maybe newer firmware versions
have been made compatible somehow... ?


> Although I was until today using openssh 8.9 just fine, it wasn't until
> the openssh 9.0 upgrade that it stopped working for me...

For me, downgrading to openssh 1:8.9p1-3 seems to work fine.

I've marked that version of openssh as hold for now, but that feels very
wrong. :/


live well,
  vagrant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnuk-users/attachments/20220411/7a822554/attachment.sig>

From gniibe at fsij.org  Mon Apr 25 04:54:48 2022
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Mon, 25 Apr 2022 11:54:48 +0900
Subject: Gnuk 1.2.20 and Chopstx 1.21
Message-ID: <87levtrhxj.fsf@akagi.fsij.org>

Hello,

Chopstx 1.21 is released.

	tag release/1.21
	Tagger: NIIBE Yutaka <gniibe at fsij.org>
	Date:   Fri Apr 22 11:14:57 2022 +0900
	commit e12a7e0bb3f004c7bca41cfdb24c8b66daf3db89

This release is from STABLE-BRANCH-1 branch.

Gnuk 1.2.20 is released.

	tag release/1.2.20
	Tagger: NIIBE Yutaka <gniibe at fsij.org>
	Date:	Fri Apr 22 11:20:32 2022 +0900
	commit 9d3c08bd2beb73ce942b016d4328f0a596096c02

This release is from STABLE-BRANCH-1-2 branch.

Those are maintenance releases.  Newer compiler is more strict, so, I
need to care about clear semantics of pointer uses (I didn't care in the
past).


If you still uses Gnuk Token < 1.2.16, the change in 1.2.16 may be
useful, with the use case of newer OpenSSH, which uses
sntrup761x25519-sha512 at openssh.com.  It requires larger data to be
signed. 

=========================================
* Major changes in Gnuk 1.2.16

  Released 2020-09-10, by NIIBE Yutaka

[...]
** Ed25519 signing allowing longer message
For OpenPGP, it does hashing on host side before requesting signing to
the device.  Thus, the length of message to be signed is limited and
determined by the hash algorithm.  That's good feature of OpenPGP.  On
the other hand, there is a use case, like OpenSSH certificate signing,
where the length of message is a kind of arbitrary.  Even though Gnuk
(or OpenPGP card protocol itself) has limitation, we removed the
length check against EDDSA_HASH_LEN_MAX at cmd_pso.
=========================================

scdaemon fix is also needed, it will be in GnuPG 2.3.6.  It is tracked
by:
    https://dev.gnupg.org/T5935
--