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

Previous Next

Package: emacs;

Reported by: Dima Kogan <dima <at> secretsauce.net>

Date: Fri, 23 Jul 2021 22:07:02 UTC

Severity: normal

Found in version 28.0.50

Done: Dima Kogan <dima <at> secretsauce.net>

Bug is archived. No further changes may be made.

Full log


Message #59 received at 49714 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Dima Kogan <dima <at> secretsauce.net>
Cc: 49714 <at> debbugs.gnu.org
Subject: Re: bug#49714: 28.0.50; TRAMP burns CPU and has insufficient user
 reporting when using xxxx-sk SSH keys
Date: Sun, 22 Aug 2021 15:06:33 +0200
Dima Kogan <dima <at> secretsauce.net> writes:

> Hi.

Hi Dima,

> From what I see, the rendering is dependent on what the window
> manager does. If you switch to another window to cover up emacs, and
> switch back, is there a redraw? I'm observing no redraw, and that's a
> problem: emacs is frozen, and I don't see the prompt text in the
> minibuffer. Sometimes due to WM quirks I never see the prompt. emacs
> should give control back to the main loop while it waits for user
> interaction (i.e. exactly what it does when asking for the passphrase).

It seems to depend on the window manager, indeed. Running "emacs -Q", I
always see the whole rendered Emacs, including the message in the echo
area. Whether I move another window on top on Emacs, and move it away
afterwards, doesn't matter.

I'm running Fedora 34 with gdm (GNOME) 40.1.

> I realize this might not be a simple thing to implement. Would it be
> simple to wait for keyboard input OR the yubikey touch, whichever comes
> first? If so, we can ask the user to "touch yubikey, or press enter to
> quit". Then the same console input code used for the passphrase input
> could be utilized here.

Not so simple to implement. We have the ssh security key message, which
must be displayed.

I've adapted the code slightly, so it doesn't wait 30 sec for the
confirmation message to appear from ssh. Instead there is a loop, which
waits for 0.1 sec, checks for the message, and calls (redisplay) if it
didn't appear.

Pushed to master. Does it make a difference for you?

> Thanks!

Best regards, Michael.




This bug report was last modified 3 years and 312 days ago.

Previous Next


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