extensibility, compatible changes, and ocap security

[Andy Wingo]

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/