On Thu, Jul 4, 2019 at 1:42 PM Phil Hofer <xxxxxx@sunfi.sh> wrote:
But the difference between GCC and this SRFI is that there is
a pretty clear definition of what behavior is _expected_ to be
safe.
Gcc was a bad choice, because of the ambiguity about the behavior
of the program itself vs. what it produces. Replace it with ls or cat
or the kernel. My trust in these programs is purely social.
I fully agree with Phil here. Of course, we can never be sure that a given sandbox or a given compiler cannot be maliciously exploited. The difference between, say, an implementation of ISO C and an implementation of SRFI 172, however, is that if a C program that should be ideally safe by the standard nevertheless allows exploits when compiled with that implementation of ISO C, we say that the implementation is buggy and can expect that the bug will be fixed.
The same is not true for SRFI 172 as currently spec'd. On a general conforming R7RS system, SRFI 172 does not offer a safe sandbox even if the implementation of SRFI 172 and the implementation of the R7RS system are without bugs.
Conversely, this SRFI, by your own admission, has "no guarantees."
Consequently, an implementation that is no safer than 'eval' is
today is perfectly conformant.
No, because this is a proposal for specific libraries. The claim is that if you
pass one of them to the `eval` procedure of a non-extreme
implementation of R7RS-small Scheme, you are better off than if you use
the interaction-environment, (scheme base), or the emulated R5RS
environment. I stand by that claim despite all doom-crying.
R7RS allows Schemes to extend the domain of the procedures in the base library and many Schemes do that. I would still call them "non-extreme".
The good thing with the interaction environment is that it is obviously not safe, so people think twice before they use it in conjunction with `eval'. On the other hand, SRFI 172 isn't safe either but people are possibly led to believe so.
The following scenario is also imaginable: Assume a portable library, which has the need to run some untrusted user code, is being developed using SRFI 172 on a Scheme system, where SRFI 172 is actually safe. People may want to use the library on other Scheme systems. Unknown to these people (who don't look too much into the library's source code), the library suddenly becomes unsafe because SRFI 172 on that other Scheme system is unsafe.
I concede that define-syntax and friends need to come out, and they will
in the next draft. I'm removing syntax-rules as well, though it is probably safe.
What about promises?
And what about, say, read? A Scheme system may have a customizable reader where extensions can call user code when special syntax is encountered. Assume the reader is customized outside the sandbox. By calling `read' on a special prepared string port, malicious sandbox code will be able to run code outside the sandbox.
What about a Scheme system that does not have undefined behavior in case of error situations, but instead prints a message and exits the program in proper form? That is if error conditions are raised that cannot be caught by user code. This would be like allowing the `exit' procedure in the SRFI 172 environment.
For example, can I intercept in Chibi the error produced by `(eval 'x (environment))'?
-- Marc
Safety features are supposed to provide guarantees.
This one does not, which is why I don't use "safe(ty)" or "guarantee".
But the relevant criterion of a SRFI is utility, not safety.
In any case, I appreciate the scrutiny, and I would ask everyone to carry on
with it.
John Cowan
http://vrici.lojban.org/~cowan xxxxxx@ccil.orgYou annoy me, Rattray! You disgust me! You irritate me unspeakably!
Thank Heaven, I am a man of equable temper, or I should scarcely be able
to contain myself before your mocking visage. --Stalky imitating Macrea