Forwarded (forgot to reply to all).
[...]
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.
Actually, this scenario is not hypothetical at all. Racket has reader extensions:
https://docs.racket-lang.org/guide/hash-reader.html. It is quite conceivable that R7RS-large (or some implementation of R7RS-small) will get something similar. As soon as such a facility is present (and it is not prohibited by R7RS-small), expressions evaluated through SRFI 172 can run arbitrary code.
While this can be remedied by removing "read" from SRFI 172 as well, it does not solve the basic problem, namely that most of the R7RS procedures are only partially specified.
Therefore, I would like to strongly suggest to remove the sample/reference implementation of SRFI 172 and to leave the implementation to each Scheme system that does want to support SRFI 172. Whether the R7RS procedures are extended (beyond the standard) in potentially unsafe ways is only known to the Scheme system and cannot be guessed by this SRFI. A Scheme system that wishes to support SRFI 172 would have to provide safe versions (e.g. a safe "read" without reader macros) for all potentially unsafe procedures.
To make this work, SRFI 172 must allow that the bindings exported by the library (srfi 172) are not necessarily compatible with the bindings exported by (scheme base), etc. The underlying types, however, shall be compatible.
[...]
Marc