From: Stefan Monnier <monnier@iro.umontreal.ca>
To: emacs-devel@gnu.org
Subject: Re: Safety of elisp-flymake-byte-compile (Was Re: [Emacs-diffs] scratch/allow-custom-load-paths)
Date: Tue, 11 Dec 2018 09:03:15 -0500 [thread overview]
Message-ID: <jwvwoogz0k5.fsf-monnier+gmane.emacs.devel@gnu.org> (raw)
In-Reply-To: 87in019dle.fsf@gmail.com
> Trust a file = loaded in the host Emacs - some known exceptions, right?
I think rather than "loaded in the host Emacs" it'll have to be "in
load-path", because Emacs is generally very liberal about automatically
loading files from load-path, so anything in load-path is
pretty much already trusted.
[ I think someone™ should sit down and think hard about this in general
(not only in the context of flymake), because "in load-path" is not as
clearly defined as we might think, since we also sometimes load files
from subdirectories within load-path.
And hopefully, this someone should be well intentioned ;-) ]
> So as soon as I load eglot.el, or eglot.elc in the host Emacs, it would
> start working?
Right, or even as soon as eglot is in your load-path.
> If so, I could live with that. Until it starts working it could issue
> some diagnostics saying "this macro is not known to be safe, so not
> checking".
Sounds OK, yes.
> Now, how would you transmit this information about safe and unsafe
> macros to from the host Emacs to the slave byte-compiling Emacs which is
> a separate process? Via command-line parameters, an .el generated on
> the fly (we already do this for the flymake'd file, btw), or something
> else?
If we use "in load-path" as the main criterion, then I think this
question is a non-issue, right?
> At least, the way I understand your solution for the "safe/unsafe" macro
> problem it still doesn't seem to fix the fact that as soon as I type
> "(launch-nuke)" into some already loaded macro in eglot.el, nukes are
> potentially going to be launched by some unsuspecting macro-expansion
> down below.
Yup. That's the problem with the use of trust as a proxy for safety.
I think if we switch to Haskell or Coq instead of Elisp we
could make all those problems disappear ;-)
Stefan
next prev parent reply other threads:[~2018-12-11 14:03 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20181204233600.7907.75252@vcs0.savannah.gnu.org>
[not found] ` <20181204233601.273DD209DC@vcs0.savannah.gnu.org>
2018-12-05 4:34 ` [Emacs-diffs] scratch/allow-custom-load-paths-in-elisp-flymake 4ef9711: Allow custom load paths in elisp's byte-compilation Flymake Stefan Monnier
2018-12-05 15:14 ` João Távora
2018-12-05 20:00 ` Glenn Morris
2018-12-05 20:40 ` João Távora
2018-12-08 13:23 ` Safety of elisp-flymake-byte-compile (Was Re: [Emacs-diffs] scratch/allow-custom-load-paths) João Távora
2018-12-08 15:36 ` Stefan Monnier
2018-12-10 0:20 ` João Távora
2018-12-10 2:22 ` Stefan Monnier
2018-12-10 23:17 ` João Távora
2018-12-11 14:03 ` Stefan Monnier [this message]
2018-12-14 12:00 ` João Távora
2018-12-14 12:15 ` Stefan Monnier
2018-12-14 13:09 ` João Távora
2018-12-14 13:27 ` Stefan Monnier
2018-12-14 13:38 ` João Távora
2018-12-14 14:13 ` Stefan Monnier
2018-12-11 19:30 ` Sandboxing (was: Safety of elisp-flymake-byte-compile) Stefan Monnier
2018-12-14 1:35 ` Sandboxing João Távora
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=jwvwoogz0k5.fsf-monnier+gmane.emacs.devel@gnu.org \
--to=monnier@iro.umontreal.ca \
--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.