[erlang-questions] Miller's oversight
Mark S. Miller
Mon Mar 26 05:39:14 CEST 2007
> This is sadly true. However, I think it is useful to distinguish
> between Erlang the language
> and the full Erlang/OTP system. If you took the language described
> in the old Erlang book and
> just removed list_to_pid/1 you would have something that was
> recognisably Erlang and in which
> process IDs were NOT forgeable. Virtually all Erlang techniques
> would survive unchanged, and
> the vast majority of Erlang code would be unaffected.
Good. Is there also an easy way to keep normal Erlang code working, but to
have it use the safe call-though-intermediate-tagging-process pattern
everywhere it currently uses the unsafe pid-reusing RPC pattern?
In order for distributed Erlang to provide distributed cryptographic
capability security between mutually suspicious machines, you'll need to
change the network representation of a pid as well -- to provide
unguessability and unspoofability, as explained in Chapter 7 of my thesis.
Currently, does the distributed Erlang protocol use crypto? How does it manage
> As a start towards this,
> (a) [...] (b) [...]
> (c) Long term, create a new 'unsafe' module and move all such unsafe
> BIFs to it.
> (Burroughs did something very like this in their NEWP language.)
We now have three good papers documenting the issues in deriving an
object-capability language from an existing memory-safe almost-capability
"The Oz-E Project:
Design Guidelines for a Secure Multiparadigm Programming Language"
by Fred Spiessens and Peter Van Roy
The Joe-E project, by Adrian Mettler and David Wagner,
"How Emily Tamed the Caml"
by Marc Stiegler and myself
Experience with all three supports your approach.
> Providing reflection facilities in a language for the sake of
> debugging (or for any other
> reason) usually seems to result in a language whose encapsulation is
> more apparent than
> real. It is for this reason that in Quintus Prolog it is possible
> (if you work at it) to
> call any predicate in any module. It is for this reason that
> Smalltalk, whose encapsulation
> of instance variables appears to be total does in fact let any object
> change any instance
> variable in any other object (using #instanceVariableAt:put:).
Flat Concurrent Prolog provided virtual meta-interpretive debugging in a way
that met the needs of security and debugging simultaneously. At
I speculate on how one might adapt these ideas to Smalltalk and similar
languages. I call the approach "refraction". Would something like this work
Text by me above is hereby placed in the public domain
More information about the erlang-questions