bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#45198: 28.0.50; Sandbox mode


From: Philipp Stephani
Subject: bug#45198: 28.0.50; Sandbox mode
Date: Tue, 29 Dec 2020 14:58:33 +0100

Am Mo., 28. Dez. 2020 um 09:23 Uhr schrieb Stefan Kangas
<stefankangas@gmail.com>:
>
> Philipp Stephani <p.stephani2@gmail.com> writes:
>
> > I agree, but we should use the time until Emacs 28 gets released to
> > gain experience with the API as well, so we should design the API
> > rather sooner than later, because once Emacs 28 is released, we can't
> > change it any more in incompatible ways.
>
> IMO, we could release it as an experimental feature and prominently
> announce that API changes might happen between major versions of Emacs.
> That would give us room to make even backward-incompatible changes,
> if/when necessary.
>
> I don't necessarily advocate this; I only want to point out that this is
> an option.

It's an option, though I'm not sure whether such announcements really
work all that well. Once an API becomes widely used, it becomes hard
to change it, even if it was announced to be unstable. Thus I'd
advocate for starting with the most conservative and malleable
approach possible:
- Don't allow reading the entire filesystem, but only selected files
and directories.
- Don't allow writing files (for now), communication should happen
through stdout. (That's probably good enough for Flymake, but soon
we'll need to find a more flexible approach.)
- Don't return a process object, but an opaque sandbox object.

For example:

(cl-defun start-sandbox (function &key readable-directories stdout-buffer) ...)
(defun wait-for-sandbox (sandbox) ...)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]