Re: Local variables insecurities - Re: One vs many directories

[Tim Cross]

Jean Louis <bugs@gnu.support> writes:

> * Eric S Fraga <e.fraga@ucl.ac.uk> [2020-11-25 16:58]:
>> On Wednesday, 25 Nov 2020 at 16:13, Jean Louis wrote:
>> > I use Mutt.
>> > The message is opened in Emacs in mail-mode
>>
>> Ah, so mutt saves content in a file which is then opened by
>> Emacs.  Okay, that makes sense.  Gnus does things the other way around:
>> opens the buffer (associated with a file in the draft directory),
>> inserts the content, and then puts the user in control.  File local
>> variables don't get a chance to be interpreted then.
>
> That is specific to Gnus. Any file opened by Emacs any will still
> invoke the dialogue for local variables.
>
>> > Then I have been testing and even text files invoke local variables.
>>
>> Yes, of course.  That's the whole point?
>
> You know that point is bad design and assumption that every user is
> programmer who knows what are local variables and what are definitions
> of Emacs functions, it is incredible situation.

I guess this is probably the main point where we disagree.

Emacs is first and foremost a programmers editor. It was never designed
as a general purpose editor, but rather specifically as an editor for
programmers.

If you jump into a formula 1 race car, you would find it almost
impossible to drive. The gearbox would be unfamiliar and difficult to
use, the clutch would be difficult to use etc. If you got it going, you
would have a high likelihood of crashing. Luckily, you would probably
just stall and get nowhere.

Is this the fault of the design of the race car or the driver? Would it
make sense to change the design of a race car to use a standard gearbox
and clutch just because at some point someone who is not a race car
driver might want to drive it?

Are there risks associated with local variables. Yes. Is there
sufficient protection against these variables being used for malicious
purposes in Emacs. I think the answer is yes. Is there any evidence of
these variables being used for malicious purpose. None that I am aware
of. Has there been bugs in the implementation of this facility - yes.
Have these bugs been addressed once identified - yes.

With respect to your email example, the number of people who are exposed
is even less - it is really only those who are using it in the same
manner as you. That is, where they have configured their mail client
(such as Mutt) to use Emacs as the external editor. None of the Emacs
mail clients I have used do this (this includes VM, mu4e, gnus,
wonderlust and mew).

anyone who has gone to the effort to configure their mail system to use
an external editor and who then answers yes to the statement
"...contains values that may not be safe. Do you want to apply it?" is
someone with inherently unsafe practices. I doubt any change in wording
or phrasing would be of any help for them. However, the correct way to
deal with this would be to offer up a patch to the Emacs developers
which improve this wording. I would suggest the set of people who are
technically aware enough or have sufficient technical interest to have
adopted emacs as their email viewer and who would still answer yes to
any dialogue warning them of unsafe actions when opening content from an
unknown source is very small.

Local variables is a powerful and useful feature. Like many powerful
features, it can be abused. We differ in our opinions on whether those
safe guards are sufficient. I believe they are and I believe you are
over stating the risks. I don't believe we will arrive at any consensus
and I feel this thread has run its course. You are of course free to
respond, but I will refrain from further participation as this has
wondered off topic for org mode and I see little to be gained from
further back and forth.


--
Tim Cross