mark .dir-locals.el buffer or file as safe instead of variables as safe

mark .dir-locals.el buffer or file as safe instead of variables as safe

[cdelia]

Hi,

new in town!

I have a .dir-locals.el (with a bunch of 'eval') on my project and I was 
trying to get rid of the confirmation popups.

Anyway, I'm not trying to get help, only presenting you the use case.

reading through info manual I found that we can only mark *variables* as 
*safe* but not a particular *.dir-locals.el* to be secure.

https://www.gnu.org/software/emacs/manual/html_node/emacs/Safe-File-Variables.html#Safe-File-Variables

I'm trying to wrap my head around this, and I, in my *very* humble 
opinion, think, it's a bad design decision.

and that's because:
One just *do not trust variables*, only *those who modify it*.
(1)


Example:

/path-to-my-trusted-land/some-project/.dir-locals.el

^ everything here should be legal, so why bother me with confirmation 
every time a open a file?

/path-to-hell-and-deprived-sleep-nights/some-project/.dir-locals.el

^ everything here should be used *with caution*, and maybe some kind of 
Virgilio to get us out of hell.

So, if a mark foo-variable, on trusted land to get rid of confirmation 
and just happen to open something on hell itself, by accident or glory, 
instead of a peak of dark magic knowledge I could let all hell break 
lose.


Could this be a feature to be implemented?
Should it be?

I newer yet dwell through the deeps of emacs C source, but I can give it 
a try if it isn't a sacrilege or there is something obvious that I'm not 
seeing.


(1) note that the inverse it's not necessary true: it's perfectly fine 
to mark variables as insecure.
Anyway, I'm not against the _possibility_ to mark variables as safe, I'm 
against the lack of a direct method to mark a buffer or a file that 
modify them, to be secure.

Re: mark .dir-locals.el buffer or file as safe instead of variables as safe

[Eli Zaretskii]

> Date: Tue, 26 Jun 2018 21:14:52 -0300
> From: cdelia@dc.uba.ar
> 
> https://www.gnu.org/software/emacs/manual/html_node/emacs/Safe-File-Variables.html#Safe-File-Variables
> 
> I'm trying to wrap my head around this, and I, in my *very* humble 
> opinion, think, it's a bad design decision.
> 
> and that's because:
> One just *do not trust variables*, only *those who modify it*.

I believe there's a possibility of someone's maliciously redirecting
your "trusted" file to another one, e.g. with a symlink.

IOW, we don't really know who modified the file and why.

Re: mark .dir-locals.el buffer or file as safe instead of variables as safe

[Phil Sainty]

On 2018-06-27 12:14, cdelia@dc.uba.ar wrote:
> So, if a mark foo-variable, on trusted land to get rid of confirmation
> and just happen to open something on hell itself, by accident or
> glory, instead of a peak of dark magic knowledge I could let all hell
> break lose.

The trust is not for a variable regardless of its value; it is for a
*specific value* of a variable.

If "hell itself" wanted to set the *same* value that was confirmed on
"trusted land" then Emacs will be happy with that; but if a different
value is used then the user will be prompted to confirm (or not) the
new value as trusted.

A variable can be defined to be a "safe-local-variable" such that a
specified predicate function can validate file-local values, and
automatically trust valid values without bothering the user. Otherwise
the user needs to confirm each distinct value independently.


-Phil

Re: mark .dir-locals.el buffer or file as safe instead of variables as safe

[Phil Sainty]

On 2018-06-27 16:24, Phil Sainty wrote:
> If "hell itself" wanted to set the *same* value that was confirmed on
> "trusted land" then Emacs will be happy with that

I should have also pointed out that variables for which this behaviour
would be unsafe are also provided for.  (elisp)File Local Variables 
says:

> Some variables are considered “risky”.  If a variable is risky, it is
> never entered automatically into ‘safe-local-variable-values’; Emacs
> always queries before setting a risky variable, unless the user
> explicitly allows a value by customizing ‘safe-local-variable-values’
> directly.


-Phil

Re: mark .dir-locals.el buffer or file as safe instead of variables as safe

[Phil Sainty]

A useful enhancement may be the ability for the user to confirm a
value as trusted only for particular contexts.  If the context was the
directory of the .dir-locals.el file (or dir-locals-directory-cache
entry), then the user could confirm (once) a trusted value for
anything covered by that .dir-locals.el and have it automatically
accepted in future for other files covered by the same .dir-locals.el;
but they would still need to confirm/trust an identical value for the
variable when specified in another .dir-locals.el file elsewhere.

(This is of course different to trusting the .dir-locals.el file
itself.)

This functionality is facilitated to an extent by the user's ability
to assign a custom safe-local-variable predicate to a variable (in
which they could test whatever contexts they wish, and return non-nil
if the context and value are agreeable).  Arguably the `eval' pseudo-
variable also gives them free rein to achieve such goals.

Still, I can see utility in supporting such functionality in a more
direct manner.


Beyond that, I've often wished I could make a particular dir-local
value "ignored" for a particular .dir-locals.el file from some
codebase that I'm working with, without necessarily ignoring it
elsewhere; so I'm now wondering whether as well as callback functions
for "safe", there should be support for callback functions for
"ignored" and "risky" as well?  And similarly, if the aforementioned
direct support for contextually-trusted values were to be added, it
would make sense to allow contextual ignore/risky there too.

(I'm not sure whether contextual-risky makes as much sense, but it
would seem odd to exclude it.)

As it is, unless I've missed something, there are cases where I must
either continually answer "no" to the prompt for accepting local
values (each time I visit a file associated with that .dir-locals.el),
or else get fed up and edit or delete the .dir-locals.el file (which
of course might be under version control, which is then awkward if I
don't actually want my change to be committed).

There are also cases when I'd like to mark *some* of the values as
permanently trusted, but might want to ignore others.

Perhaps as well as the y/n/! options, there could be a new binding to
invoke a more advanced UI for deciding what to do with the values on a
per-variable basis.  Contextual behaviour options could be exposed in
that UI.


-Phil