[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Safety of elisp-flymake-byte-compile (Was Re: [Emacs-diffs] scratch/

From: Stefan Monnier
Subject: Re: Safety of elisp-flymake-byte-compile (Was Re: [Emacs-diffs] scratch/allow-custom-load-paths)
Date: Fri, 14 Dec 2018 07:15:42 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

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

Cute worms, by the way.

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

If it is in your load-history, then it also qualifies to be "trusted",
even if it's not in your load-path.

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

It's particularly serious when that someone is yourself, because
when you mess up you can't even point fingers.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]