bug#38265: 26.3; lock file is too easy to steal

bug#38265: 26.3; lock file is too easy to steal

[Allen Li]

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).

In GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.10)
 of 2019-08-29 built on juergen
Windowing system distributor 'The X.Org Foundation', version 11.0.12005000
System Description:	Arch Linux

bug#38265: 26.3; lock file is too easy to steal

[Juri Linkov]

> 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?

bug#38265: 26.3; lock file is too easy to steal

[Juri Linkov]

>>> 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?

bug#38265: 26.3; lock file is too easy to steal

[Allen Li]

Juri Linkov <juri@linkov.net> writes:

>>>> 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?

Tried how?  I have not tried to patch the (discard-input) change to
check executing-kbd-macro, nor tried whether the (discard-input) change
addresses the concern in the original bug.

bug#38265: 26.3; lock file is too easy to steal

[Lars Ingebrigtsen]

Allen Li <darkfeline@felesatra.moe> writes:

> 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).

I think making the lock prompt more extensive would be pretty
annoying -- we only use yes-or-no-p (and related) when doing something
destructive or dangerous, and stealing the lock isn't that dangerous.

So I think the current level of prompting is fine, and if you want more
prompting, then it should be easy enough to redefine/advice
ask-user-about-lock to be harder to get past, and I'm closing this bug
report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no