From: cdelia@dc.uba.ar
To: emacs-devel@gnu.org
Subject: mark .dir-locals.el buffer or file as safe instead of variables as safe
Date: Tue, 26 Jun 2018 21:14:52 -0300 [thread overview]
Message-ID: <d0ebecade06de0dcdf602bc66d0fb147@dc.uba.ar> (raw)
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.
next reply other threads:[~2018-06-27 0:14 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-27 0:14 cdelia [this message]
2018-06-27 2:33 ` mark .dir-locals.el buffer or file as safe instead of variables as safe Eli Zaretskii
2018-06-27 4:24 ` Phil Sainty
2018-06-27 4:34 ` Phil Sainty
2018-06-27 6:36 ` Phil Sainty
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d0ebecade06de0dcdf602bc66d0fb147@dc.uba.ar \
--to=cdelia@dc.uba.ar \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.