bug#45198: 28.0.50; Sandbox mode

[Stefan Monnier]

[ I'm afraid I dropped out of the discussion, so I may lack some
  context.  ]

> What I meant is that there is no way of knowing whether an API is rubbish or
> not without having put it to use ourselves first (preferably in two or more
> ways), so let's not front-load the design. We know that this is true
> regardless of how good programmers we think we are. 
> Flymake would be a natural user, but it must cope with our own demands first.

IIUC the discussion surrounds mostly around restricting
file-reads, right?  I agree it'd be good to have a sandbox that
restricts file-reads, but we should think about how to design such
a thing, i.e. how to specify (and then enforce) which files can be read.

My experience with the GNU ELPA scripts using bwrap is that it might not
be easy: we definitely don't want to give read access to /etc, yet it
seems very likely that some files in /etc may be needed, even in very
mundane circumstances (e.g. /etc/alternatives or /etc/emacs or ...).
This gets quickly very OS-dependent (and doesn't depend just on
Windows-vs-GNU/Linux but varies also between distributions of
GNU/Linux).  If we stick to an "in-process" sandbox (i.e. you can't run
sub-processes) it makes this a bit simpler (you don't need to worry
about read access to /lib vs /lib64 and other such things), so maybe it
is manageable.  But I think the starting point would be to give read
access to everything that's under one of the directories mentioned in
`load-path`.

> There's a difference though: flycheck is installed by someone who wants to
> use it and is presumably ready for some setting-up. In contrast, we are
> aiming at an on-by-default zero-configuration Emacs feature, which means
> that the bar is higher. It's meant precisely for those who would not install
> and configure flycheck, so false positives may have effects opposite
> the intended.

Indeed, in order to enable flymake by default we're going to have to be
extra careful to try and make sure the user isn't smothered in warnings.
That probably means for example to keep flymake disabled when visiting
the init file.

>> 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'.
> I don't necessarily disagree but it would be interesting to hear what Stefan
> thinks about it. Since it's somewhat of an opinionated tool after all, it's
> squarely within our remit to lay down policy...

I must say I don't know what's being discussed here.
What autoloads?  Why do we care?


        Stefan