Escape via unhygienic macros Phil Hofer (03 Jul 2019 23:31 UTC)
Re: Escape via unhygienic macros John Cowan (04 Jul 2019 03:59 UTC)
Re: Escape via unhygienic macros Marc Nieper-Wißkirchen (04 Jul 2019 05:57 UTC)
Re: Escape via unhygienic macros John Cowan (04 Jul 2019 17:03 UTC)
Re: Escape via unhygienic macros Phil Hofer (04 Jul 2019 19:02 UTC)
Re: Escape via unhygienic macros John Cowan (04 Jul 2019 18:55 UTC)
(missing)
Fwd: Escape via unhygienic macros Marc Nieper-Wißkirchen (08 Jul 2019 12:21 UTC)
Re: Escape via unhygienic macros Marc Nieper-Wißkirchen (08 Jul 2019 12:38 UTC)
Re: Escape via unhygienic macros John Cowan (08 Jul 2019 16:28 UTC)
Re: Escape via unhygienic macros Lassi Kortela (04 Jul 2019 19:45 UTC)
Re: Escape via unhygienic macros Lassi Kortela (04 Jul 2019 19:56 UTC)
Re: Escape via unhygienic macros John Cowan (08 Jul 2019 04:57 UTC)
Re: Escape via unhygienic macros Marc Nieper-Wißkirchen (04 Jul 2019 20:27 UTC)
Re: Escape via unhygienic macros Lassi Kortela (14 Jul 2019 15:41 UTC)
Re: Escape via unhygienic macros John Cowan (14 Jul 2019 17:59 UTC)

Escape via unhygienic macros Phil Hofer 03 Jul 2019 22:59 UTC
Hi all,

Marc makes an excellent point about potential sandbox escape via
undefined (or implementation-defined) behavior, but
I'd like to point out another escape route: syntax transformers.

If the R7RS implementation uses an expander similar to
the Chez syntax-case expander, then it is possible to
construct syntax objects without direct access to the
syntax or quasisyntax reader macros. (In that particular
implementation, syntax objects were simply vectors with
a sigil in the first vector slot.) If the implementation
does hygienic renaming as part of expansion, then it would
be relatively straightforward to write an unhygienic macro
that was able to access bindings outside the explicit binding
environment that was passed to 'eval'.

Consequently, a "safe" subset of R7RS must restrict the
implementations of define-syntax, letrec-syntax, etc. to
only accept hygienic syntax transformers. I think some
implementations may have trouble guaranteeing this restriction
in practice.

I also think it might be worth reconsidering the use of the
words "safer" in the title of this SRFI. It's not clear
what "safer" means in this context: what security guarantees
are we actually trying to achieve here? Maybe "sandboxed eval"
would be a better name. But it would still be helpful to iron
out what the threat model is supposed to be here (are side-channel
exploits in scope here? How about local DoS? etc.)

Cheers,
Phil