GNU bug report logs - #45198
28.0.50; Sandbox mode

Previous Next

Full log

View this message in rfc822 format

From: João Távora <joaotavora <at> gmail.com>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: Bastien <bzg <at> gnu.org>, 45198 <at> debbugs.gnu.org, Philipp Stephani <p.stephani2 <at> gmail.com>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: bug#45198: 28.0.50; Sandbox mode
Date: Sat, 19 Dec 2020 19:48:18 +0000

On Sat, Dec 19, 2020 at 6:47 PM Mattias Engdegård <mattiase <at> acm.org> wrote:
>
> 19 dec. 2020 kl. 19.11 skrev Stefan Monnier <monnier <at> iro.umontreal.ca>:
>
> > I must say I don't know what's being discussed here.
> > What autoloads?  Why do we care?
>
> If a user looks at elisp code that depends on autoloads and the checker process cannot load those for reasons of sandbox policy or whatnot, there will be false positives about missing functions. This is fine if we are phasing out autoloads but as far as I know we're not.

It would have to depend on autoloads at compilation time.  As far as
I can tell, that's not extremely common.  It's quite more common
that things are `require`d and thus `load`ed at compilation time,
so if we block that, the Flymake compilation output becomes quite
useless in most cases, producing big single error in that first require.

Such things can and already do happen with processes that
have non-standard  load-paths mechanisms, such as one of mine.
The only load-path that the Flymake currently sees is the current
directory's.  I suppose extending that is possible (and it's been in my
plans). It's also possibly another "hazard", though one incurred in
consciously by the user,  whom we may warn via the usual "unsafe
local variables" machinery.

João

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.