Hi, I was compiling guile-gnome recently, saw a warning about a srfi-39 binding replacement, and went to go look at srfi-39 in Guile. That's the `parameterize' library, you see. It is unnecessary, given that `parameterize' is now in boot-9, but there is a wrinkle: srfi-39 requires that `current-input-port' et al be implemented as parameters.
Currently, `current-input-port' in boot-9 is a procedure of 0 arguments. We can change it so that it has an optional argument, which would be the equivalent of calling `set-current-input-port!' on the arg. However, this effectively gives another /capability/ to anyone that has access to the previously idempotent `current-input-port' procedure: namely, the ability to change the current input port. The question is, can we make this change in the default Guile? (If you don't implement sandboxes for your users, the rest of this mail doesn't apply to you.) After some thinking about this, I think that the answer is "yes". If you are providing an ocap-style environment to untrusted code, then you need to prevent Guile from making extensions to your interface that can compromise your security invariants. We have added optional and keyword args to other interfaces in the past. The kinds of extensions that Guile could make within a stable series are all of the form, "evaluating FOO produced a wrong-number-of-arguments error in guile 2.0.3, but in 2.0.4 we have made it do useful action BAR." We promise that existing uses will still work, so it's not like you have to implement your own environment entirely, but you do need to make a number of proxies (whether as procedure wrappers or identifier-syntax or whatever). So that's what I'm thinking right now. Other thoughts are welcome as well. Happy hacking, Andy -- http://wingolog.org/
