GNU bug report logs - #49714
28.0.50; TRAMP burns CPU and has insufficient user reporting when using xxxx-sk SSH keys

Previous Next

Full log

View this message in rfc822 format

From: Dima Kogan <dima <at> secretsauce.net>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 49714 <at> debbugs.gnu.org
Subject: bug#49714: 28.0.50; TRAMP burns CPU and has insufficient user reporting when using xxxx-sk SSH keys
Date: Wed, 28 Jul 2021 12:58:58 -0700

Michael Albinus <michael.albinus <at> gmx.de> writes:

> Well, while you see the message, Tramp is looping with
> accept-process-output in order to check, whether the yubikey has been
> pressed. This is not different from everything else Tramp does, until
> the remote shell prompt has been detected. So I don't see what we
> could do otherwise ...

I understand this argument. However, as a user, I would fully expect
emacs to behave the same way while it's waiting for the passphrase as it
does when waiting for me to touch the yubikey. Currently the passphrase
input stage feels normal, while the wait-for-touch stage feels frozen.
On a deeper level, in both cases we're waiting for some specific data to
come from an OS file descriptor: either something ultimately connected
to the keyboard, or the ssh process. Maybe this isn't worth the effort
to fix, but it is a problem.


> Btw, there is a timeout of 30 seconds. When you don't press the
> yubikey during this time, Tramp shall cancel the authentication
> process. Perhaps you could give this also a short test?

Yes. Let me do that later today. The passphrase query itself (from ssh,
unrelated to emacs) has some timeout too, which maybe expires before 30
sec. I will check.

Thanks so much for implementing this!

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.