Re: Risky local variable mechanism

[Luc Teirlinck <teirllm@dms.auburn.edu>]

Chong Yidong wrote:

   How about this patch?  It implements a `safe-local-variables' custom
   option.  If a variable is not in this list, the user is prompted
   before it is set.  If the user agrees to set it, and the variable is
   not explicitly marked as risky (as determined by the currently
   existing `risky-local-variable-p' function), we ask if that variable
   can be automatically set in the future.  If the user agrees to this
   too, `safe-local-variables' is updated and saved to the custom-file.

After realizing what we are really trying to do, I believe that this
makes little sense.

Most users have no idea how to determine whether an Elisp variable is
always safe to set as a file local variable.  When asked whether they
want to set the file local variables as set in the -*- line or the
local variables list, most users ask themselves: "Who wrote this file,
who might have had access to this file since I last visited it, and do
I trust these people?".  In practice, this is the best most people can
do.

You ask not one, but two, questions for _each_ file local variable
that is not explicitly marked safe, which will mean the vast majority
of variables.  Most users do not know enough to _ever_ answer yes to
your second question and if the file contains say five local
variables, we will keep asking them ten questions each time they visit
the file.  That is saying to the user:
"You _better_ agree to let anybody set these variables to any value
whatsoever or else we are going to keep harassing you with these ten
questions for all eternity.  You already pressed `y' once, because you
trust the person who wrote this file.  You have your finger already on
the `y' key.  Just press it a second time and trust _everybody_."

Also, the involved defcustom's are _very_ problematic.  The many Custom
problems regarding listvars I mentioned earlier are _not_ minor.
For instance, one serious problem is that if one would, for a
subsequent Emacs version, _have_ to add variables to the default of
one of these defcustoms, because these variables are obviously safe
and often encountered, or much worse, obviously extremely dangerous,
then any user who customized them in the prior version will never get
his customized values updated, which may be very dangerous, if some
very dangerous new variable was introduced.

I believe that it would be much better to show the user the -*- line
and the Local Variables list (at most one of the two should normally
be present) and ask the user whether he wants to set the variables.
That is one question per file (or at worst two, but that should very
seldom happen in practice).

One can accomplish this by setting enable-local-variables by default
to 'maybe.  At present, this still has the drawback that the question
is asked even if the file only sets _obviously_ safe variables.  I
believe that these include `coding', `mode', `byte-compile-dynamic'
and a few other often used ones.  (I must admit that I am not even
completely sure myself exactly which variables are safe to set to any
value whatsoever.  I wonder how somebody who does not know Elisp might
manage to do that.)  We might fine tune enable-local-variables not to
ask any question if all of the variables are safe pseudo-variables or
are safe to set to the given value as determined by the
safe-local-variable property.  No new defcustom needed.

Sincerely,

Luc.