bug#45198: 28.0.50; Sandbox mode

[Philipp Stephani]

Am Fr., 18. Dez. 2020 um 19:50 Uhr schrieb Mattias Engdegård <mattiase@acm.org>:
>
> 18 dec. 2020 kl. 16.21 skrev Philipp Stephani <p.stephani2@gmail.com>:
>
> > Ah, I was talking about the engineering/product management aspect, not
> > about the technical one: If you start with an initially-open sandbox
> > policy, locking it down in future releases is much harder than the
> > other way round.
>
> I assumed we were just building a mechanism for our own consumption at this 
> stage, even if the eventual aim is something available for general use.

I'd say these two questions are somewhat independent of each other.
Even with an internal-only interface, people will start to assume that
reading arbitrary files works.
I'm personally not a huge fan of such internal interfaces though. They
are necessary in some cases, but a high-level UI framework like
Flymake shouldn't need to use them. Besides, since Flymake is released
as an external package, it should rather not use internal interfaces
in the first place.

>
> >  We
> > should definitely run the subprocess with --quick --batch and an empty
> > environment by default, not only for security and speed, but also for
> > reproducibility. That's also what Flycheck does
> > (https://github.com/flycheck/flycheck/blob/a11b789807d1d942d6fcfac17508d072b9cf7ba8/flycheck.el#L8435)
>
> Thanks for the reference, and you may very well be right. A counterpoint is 
> that since the facility would be enabled by default, a user met with 
> complaints about perfectly fine code will immediately disable the checks and 
> thus foil our plan to nudge his coding habits in a desirable direction.

Maybe, though I wouldn't be so sure. Elisp compilation in Flycheck is
enabled by default and presumably suffers from the same problems.
There are also similar problems with other languages: for example,
when I visit src/lisp.h and enable Flymake, I get 2287 errors, 154
warnings, and 4002 notices (which is an actual problem since the huge
number of overlays makes Emacs sluggish - probably Flymake should just
stop after 20 diagnostics or so...). I totally agree that we need to
keep the false positive rate low, but I wouldn't say that any nonzero
rate would make Flymake useless.

>
> I take it that you don't suggest that we skip on loading autoloads (possibly 
> in the shape of quickstart) though? A bit rough to byte-compile without 
> those, unless we deprecate autoloads altogether.
>

Good question. I'd say we disable them initially and see what happens.
It'll be a while until Emacs 28 gets released, so we have enough time
to gather feedback and make adjustments.
I also think that packages shouldn't rely on autoloads from other
packages. I generally dislike autoloads and think they are overused.
They make programming unnecessarily brittle because they assume not
only that the load path is set up correctly, but also that the correct
loaddefs files are already loaded. Autoloads are probably fine for
interactive commands to avoid unnecessarily loading rarely-used
packages, but inter-package dependencies should just use 'require'.