bug#48452: 28.0.50; flymake for elisp does not respect `load-path`

[João Távora]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> João Távora <joaotavora@gmail.com> writes:
>
>> If you don't elaborate, we have no way of understanding whether this
>> is a genuine expansion of the "disaster vector" that is already
>> intrinsic to this particular Flymake backend.
>
> I think I already mentioned the problem of editing files in /tmp/?
> That's the whole point of not having ./ in load-path -- you can
> inadvertently load code under control of an attacker.

As I've been trying to explain, flymake-elisp-byte-compile is all about
"inadvertently loading code": it's -- literally -- constantly and
largely unpredictably byte-compiling a file containing the transient
contents of your buffer.  As you know, in Lisp, that is always running
code, arbitrary code.

It's not at all comparable to the interactive Emacs usage where the user
takes voluntary action to execute something.

Flymake in Elisp files is inherently insecure in this respect.  This is
why we don't turn it on by default.  Maybe this should feature more
prominently somewhere: "Users must NOT turn on
flymake-elisp-byte-compile automatically if they are not aware of the
risks."

At some point in the past, Stefan was working on a "sandboxed" Emacs
that could, in theory, pave the way for automatically enabled Elisp
Flymake, but I haven't heard of that effort lately.

> It seems to me that there's two useful values for load-path in the
> Flymake backend: Either just the standard load-path (so that you
> actually get the same results as when doing a batch byte-compile) or the
> current running load-path (so that you get the same results as when you
> `require' the file from your .emacs, say).  Altering the load-path to
> also include the ELPA directories doesn't really help much, because
> people have all kinds of code that's not in ELPA (but is in their
> load-path).

I think we have to ask ourselves: what is Flymake used for?  The most
useful answers will come from the people who actually use it, though
potential uses are also interesting.

I for one use it to develop Elisp package.el packages that I later
publish to GNU ELPA and MELPA so that other users, my "clients", are
to be able to use in their Emacsen.

The ELPA packages _I_ develop only ever depend on packages in Emacs core
(at most they are :core ELPA packages).  But it seems, quite reasonably,
that Max's packages do also depend on packages that are not in Emacs
core, but in some xELPA repo.

Why is Flymake useful to me in the state it is now?  Because, given a
transient state of my Elisp buffers, it helps accurately predict the
byte-compilation warnings and errors that those clients would experience
were they to grab and install my package at state I have it in front of
me.

Having './' in the default load-path for elisp-flymake-byte-compile is
fundamental for the accuracy of this prediction.  Why?  Because the
clients of my packages -- regardless if they use package.el,
straight.el, etc or just simply using a git checkout -- will always have
the the files I have in some directory in some other directory in their
machines, and _that_ directory will be in the load-path.

Can Flymake be useful in some other situation?  Perhaps, who knows?  But
I for one never use it to obtain largely the same results I can already
get with M-x elisp-byte-compile-file.  But if you do want to use it like
that, feel free to add an option to inherit the current session's load
path.

I'd say we should first fix Max's problem, this bug report's problem,
which I can perfectly understand.  I think the correct way is with the
patch I submitted, though we can also ask max to add the path of each of
his package's dependencies to some dir-local value of
elisp-flymake-byte-compile-load-path.  Not very practical, IMO.

Finally, if you want to remove "./" from the automatic load path of
elisp-flymake-byte-compile, no problem.  It's of course your call: I'll
just add it to elisp-flymake-byte-compile-load-path in my session and be
done with it.  IMO Something like this could be justified if it were
plugging an important security hole.  But in my opinion we're closing a
window in a house with no roof and doesn't justify breaking people's
workflows.