GNU bug report logs - #38265
26.3; lock file is too easy to steal

Previous Next

Full log

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

From: Juri Linkov <juri <at> linkov.net>
To: Allen Li <darkfeline <at> felesatra.moe>
Cc: 38265 <at> debbugs.gnu.org
Subject: Re: bug#38265: 26.3; lock file is too easy to steal
Date: Mon, 16 Dec 2019 02:04:39 +0200

>>> The default ask-user-about-lock is too easy to miss.
>>>
>>> For example, if one were typing "asparagus", they would likely steal the
>>> lock without even realizing that it happened (the "a" triggers the
>>> prompt on buffer modification and the "s" steals the lock).
>>>
>>> It would be nice to have the prompt be harder to hit accidentally, such
>>> as making all of the keys uppercase or having to type them out like
>>> yes/no (but the latter might be too heavyweight).  Or the prompt should
>>> have a short timeout before allowing the user to respond (like how
>>> yes-or-no-p does when you provide an invalid response).
>>
>> On the request in https://lists.gnu.org/archive/html/emacs-devel/2019-11/msg00517.html
>> recently ‘(discard-input)’ was removed from ‘read-char-from-minibuffer’.
>> Should it be put back?
>>
>> ask-user-about-supersession-threat uses read-char-from-minibuffer, so if
>> it contained ‘(discard-input)’ it could benefit from discarding such
>> inadvertent input as "s".
>>
>> But what about the case of keyboard macros like in the link above?
>> What if the user recorded a keyboard macro to input that "s" intentionally?
>
> We could check executing-kbd-macro and disable "interactive safety
> features".  That seems like a valid use case of executing-kbd-macro.

Yes, executing-kbd-macro could help.  Have you tried it?

Previous Next

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