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

[João Távora]

Stefan Monnier <address@hidden> writes:

> I'm saying "without another traversal of the code".
> I.e. elisp-flymake--batch-compile-for-flymake would just call the
> byte-compiler in a different way (either via a new entry-point, or by
> let-binding some new variable) to cause it to be more careful (and not
> worry about generating correct&efficient code).

OK. Got it.

> The macros defined in the flymake'd file wouldn't need any declaration:
> they'd all be treated as suspicious and checked via `unsafep`.
>
> For the macros defined in already-loaded packages, I'm not sure
> what would be the better option between a whitelist (such as the 
> `flymake-safe`
> declaration above) or a blacklist or something in-between.

Hmmm.  The way I'm understanding this now, I'd favor a blacklist,
because it seems that you are proposing that anything that is loaded in
the main Emacs (call it "host" or "master"), is already safe,
except for some known misbehaving macros.

>> But then we would have to prompt the user to accept or reject these
>> marks right?
>
> Since they're in the files we already trust I don't think that's
> needed.

Trust a file = loaded in the host Emacs - some known exceptions, right?

>> I don't think I completely understood your idea: what about, for
>> example, eglot.el's macrology that checks LSP interface destructuring at
>> compile-time?  There are some eval-when-compile's there right now:
>>
>>   (eval-and-compile
>>     (defvar eglot--lsp-interface-alist
>>       `(
>>         (CodeAction (:title) (:kind :diagnostics :edit :command))
>>         (Command (:title :command) (:arguments))
>>         ...)
>>         "Alist of (INTERFACE REQUIRED-KEYS OPTIONAL-KEYS)"))
>>
>> And then
>>
>>    (eglot--dbind ((Command) title not-really-a-key) some-lsp-object
>>      (do-something-with title not-really-a-key))
>>
>> gives me a nice warning that not-really-a-key isn't in the "Command"
>> interface.  How would that work in your new elisp-flymake-byte-compile?
>
> It would only work once `eglot--dbind` is defined by a pakage in
> `load-path` (and after that package defined
> eglot--lsp-interface-alist).
>
> But not if you just open eglot.el.


So as soon as I load eglot.el, or eglot.elc in the host Emacs, it would
start working?  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".

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?
>
>> Also, what do you think of my option 2 to disable most of the system
>> interface when flymaking?
>
> Providing ways to run Elisp in a confined environment would be useful in
> various circumstances, but it's non-trivial.

I can understand that, but I'm not proposing a fully hermetic sandbox
just something that ameliorates the problem.

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.  So I'd like at least to have a slave emacs with main
nuke-launching facilities disabled, even if there are almost certainly
ways to circumvent that.

João