Re: Safety of elisp-flymake-byte-compile (Was Re: [Emacs-diffs] scratch/allow-custom-load-paths)

["João Távora" <joaotavora@gmail.com>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> 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 ;-)  ]

This is orthonogal to the question right?  I think for the time being we
can write some 'moderately-trusted-p (file)' function to hide that can
of worms.

>> 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.

Hmmm, there appears to be a contradiction here, or maybe I'm missing
something.  Can you explain exactly what will happen if I C-u M-x
byte-compile-file the eglot.el file?  That's the way I normally load .el
files: I usually don't put their directories in my load path unless they
have complicated dependencies, or I plan on keeping them in my config.

So, shouldn't we instead/also use 'features'?

>> 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.

Good to have this one nailed down.

>> 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?

We still have to hand the host's load-path/features value to the slave
Emacs, 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.

Yup x 2.  With Flymake and macro expansions it's like you trust someone
to be reasonable, but then he turns into a nuke-lanching maniac just by
joking about it.  Better not have nukes handy by then.

João