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

[Tom Gillespie <tgbugs@gmail.com>]

Hi Jean,

Some points in summary before a long email.
1. Having an accepting default behavior as a user (i.e., saying yes to
   all prompts) is bad security practice. The only thing that systems
   can do is prompt as infrequently as possible in hopes that people
   don't get prompt fatigue. Emacs does this.
2. If mutt is launching Emacs, you can pass --eval "(setq
   enable-local-eval nil)" on the command line and all file local
   variables will be ignored and treated as plain text.
3. If people don't read the manual and don't read the prompt, there
   isn't much more that Emacs can do while still empowering the
   user. In those cases we also can't assume that the community will
   be of much help either, as we are trying to be here.
4. That said, the local variables prompt could be more alarming and
   provide a quick way to access the manual about local
   variables. I'll look into a patch for that.

Now on to the rest!

Full disclosure. I make use of file local variables every day
and I have spent quite a while writing orgstrap which relies heavily
on them, so I am definitely biased.

Emacs is a sharp tool. Experts need sharp tools. If someone complains
about the security of prompts but also admits that they always say yes
to prompts without reading them, then no one will take them seriously
when they try to argue that it is the prompt that is insecure. It is
like complaining that the forest is dangerous while insisting on
eating the berries of all the plants and picking up all the snakes.
The forest is dangerous, but not merely because the berries and the
snakes exist in it. Heck, some snakes even try to warn you! There are
some rattlesnakes that have evolved to not rattle because idiot humans
go find and kill them. Now everyone suffers because there are silent
rattlesnakes that will strike without warning.

Degrading usability because some users are irresponsible just
reinforces the irresponsible behavior and everyone loses. The endgame
for all prompts is a two-man two-key system where the switches are
separated by 30 feet and must be turned within 1 second of each
other. How else could we be sure that the user really meant to say
yes!? Emacs is scary, but not nuclear launch system levels of scary.

Furthermore, Emacs does try to account for users who don't read the
manual and has sane and safe defaults. Namely it does not blindly
execute code but prompts the user and lets them know that something is
going on. Further, when it prompts the user it does not provide a
default action, it forces them to answer so that they must attend to
what they are doing. This provides the user with an opportunity to
become aware of a feature of Emacs that is new to them. The only other
option is to never execute local variables until a user reads the
manual and changes their config. Such a design infantilizes the user
and does not empower them.

Emacs isn't just a dissociated tool, or at least it tries not to be
(lots of people also complain about the splash screen being enabled by
default!). The Emacs community often also goes out of its way to share
its knowledge when such situations arise (as we are doing here). We
can't reach everyone (yet!) but many people donate time and effort to
share. Emacs and Org both actively encourage users to participate in
the mailing lists because venues like StackOverflow are not guaranteed
to be seen by the community and are not officially supported.

Finally on this point, if we are willing to open the manual we see
that Emacs tries to educate users about this, the first line of the
section on file local variables is "File-local variables can be
dangerous."

With regard to the local variables prompt. Maybe the right thing to do
in this case would be to add a "?" option so that users can open the
manual? That seems like it would help. That said, the second line of
the prompt reads "contains variables that may not be safe (*)" which
should be alarming. I guess it could be changed to "THIS FILE COULD
PWN YOU. Please review potentially unsafe variables marked with an
asterisk (*)." Or just make the second line a bold warning? I have a
patch I need to send in to make it possible to use lexical scope in
eval local variables, I'll take a look at this while I'm there.

It is forgivable to not be utterly terrified of systems that can
execute arbitrary code, given that they mostly look like rocks, and we
are surrounded by them all day. However, they are utterly terrifying
existences! While I think it would be great for the Emacs splash
screen to come with a big warning that says "WARNING THIS PROGRAM
ENABLES YOU TO EXECUTE ARBITRARY CODE" I admit that it took me nearly
a decade to begin to understand what arbitrary code execution means
and why I should be scared of it. Those words are meaningless to a 12
year old who at best will think "What is the big deal about arbitrary
code? I can already run any code that I want!"

This is why I pointed you to orgstrap. The eval: (org-sbe startup)
local variable is utterly terrifying to me. I added a layer that
allows me to know that I have audited the block that I'm about to
execute by calculating the checksum of the elisp. Now we have an
audited code evaluation system. Much less terrifying, with a chance to
prevent nasal demons rather than playing prompt fatigue roulette and
hoping it is never my turn. I can't read the instructions for you nor
explain better than the link itself https://github.com/tgbugs/orgstrap
why you might want to use it if you care about security while still
wanting to run code to simplify complex processes.

You ask why people need local variables in the first place. The answer
is partially because they got sick of getting emails from people who
had misconfigured systems and didn't read the manual and the
instructions for how to properly configure them to run a file (sound
familiar?). They also got sick of people screwing up the indentation
of files and not following coding conventions, so they got the
computer to do it for them because it is way more effective than
trying to do it with politics.

People who don't follow instructions don't follow instructions. This
seems like an obvious statement, but its consequences are nearly
impossible to deal with and there is not much we can do about it other
than to reduce the number of instructions we have to give. Local
variables are a great way to reduce the number of instructions. I have
tested this (unscientifically) and I can report that error rates are
lower and users are happier when they can accept local variables and
let the author of the file worry about the details. Hard to follow
instructions waste everyone's time if they are followed at all. There
are better workflows, but they are not foolproof and not obvious. How
could they be? Few to none are born knowing cryptography much less the
best practices for how to employ it.

People put up fences and warning signs, and some folks will still
climb over them. I suppose we could go back to only using Turing
incomplete systems and languages.  Those are probably safe.

As alluded to in one of my previous emails, questioning the existence
of a feature is often a sign to slow down and take the time to
understand what you might be missing. Sometimes there is nothing
there, but in Emacs that is rarely the case. To quote myself "Emacs is
useful because countless others have encountered problems the likes of
which a single person only rarely dreams. Not only that but they have
probably already implemented a solution that is fairly easy to find
once you encounter the problem and in 80% of the cases can be used
unmodified."  There are features of Emacs that I suspect I will never
know about no matter how long I use it and that is as it should be.

There are members of the larger community who I suspect have seen
countless users, some new, some veteran, come to question and complain
about a feature that they rarely personally use and thus do not
understand. Such observers know from experience that there are likely
thousands of other users for whom that very feature is a critical part
of their daily workflow. Someone posted to this list a few months ago
suggesting that org be stripped of all the complexity and broken into
smaller projects because they didn't see the need to include things
like org-babel in the core.  Fortunately the community has long
experience with these kinds of limited perspectives and knows how to
deal with them, but they cannot simply be ignored.

Best,
Tom