1. 6

  2. 3

    Here’s the documentation on the new (ice-9 sandbox) module. It includes a pretty great quote:

    Sometimes you would like to evaluate code that comes from an untrusted party. The safest way to do this is to buy a new computer, evaluate the code on that computer, then throw the machine away. However if you are unwilling to take this simple approach, Guile does include a limited “sandbox” facility that can allow untrusted code to be evaluated with some confidence.

    1. 1

      Physical separation as default was in a comment I just posted:


      Unpopular but safest option. Wise of them to say that albeit it looks like a joke, too. A modification of that idea that goes way back is to use ROM’s for all firmware w/ removable storage. Then, the most they can do is damage the hardware (DOS attack). Their changes go away when you reboot the machine. Might have to do a custom job for that these days unless you’re fine with embedded boards. Some of them still have ROM in combination with flash that can store a signed image.

    2. 2

      Guile can run interactively, as a script interpreter, and as a Scheme compiler to VM bytecode.

      I understand that bootstrapping/self-hosting necessitates keeping around both a compiler and an interpreter, but I don’t understand why the interpreter in this case would be exposed to the user. Isn’t it always better to compile it down to bytecode and run that and leave the interpreter as an internal implementation detail?

      1. 1

        Interpretation and compilation are closely related with similar risks. However, I prefer that option so an untrusted process with about no privileges can load and compile the risky code. Then, that code can run with minimal privileges and runtime necessary.