GNU bug report logs - #45198
28.0.50; Sandbox mode

Previous Next

Full log

View this message in rfc822 format

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

18 dec. 2020 kl. 16.21 skrev Philipp Stephani <p.stephani2 <at> 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.

>  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.

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.

Previous Next

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