[e-lang] An object-capability subset of Python

Ph.T dr.addn at gmail.com
Sun Sep 14 21:29:58 CDT 2008

> . it could be self-fulfilling to assert
> "If you think that Python can be made into a capability system
> then you do NOT understand Python!"

    . I think one can understand the Python language from its name:
a python tackles its problem by getting at first loosely wrapped around it,
working quickly just to grasp the solution,
and when the solution is understood, the fit gets tighter,
and eventually your solution is familiar enough
to constrict it into some compact c code .
. for rapid development, the language has to make Pythonistas feel free,
and at this early part of the development
we want to protect ourselves from them with sandboxing, and journalling;
whereas, e-lang would be a better fit replacing the c code
-- where most of the meat -- and vulnerability -- of the Python is .

    . I recently joined this mailing to help me become familiar with
and am still unfamiliar enough with security issues
to not feel very confident with anything less than sandboxing with vmwares,
and having operating sytems that can understand their code,
like the way .net/mono can .

On Sun, Sep 14, 2008 at 2:29 PM, Mark Seaborn <mrs at mythic-beasts.com> wrote:

> zooko <zooko at zooko.com> wrote:
> > In contrast Guido van Rossum, when I spoke to him at the most recent
> > PyCon, emphatically told me "If you think that Python can be made
> > into a capability system then you do NOT understand Python!".
> > Shortly thereafter he ended our conversation in order to be
> > interviewed by a journalist.
> Unfortunately that attitude can become self-fulfilling.
> I discovered last week that there is a change in Python 3.0 that makes
> it harder to make Python safe.
> Python 3.0 is removing unbound methods from the language.  In Python
> 2.x, if you retrieve a function from an attribute of a class, it gets
> wrapped by a "unbound method" object which adds a type check.
> Currently CapPython depends on this type check being added.
> Suppose there are two unrelated classes:
> class C(object):
>    def __init__(self):
>        self._field = "secret"
> class D(object):
>    def method(self):
>        return self._field
> If you try to use D.method (an unbound method) on an instance of C it
> raises a TypeError:
> >>> c = C()
> >>> D.method(c)
> TypeError: unbound method method() must be called with D instance as first
> argument (got C instance instead)
> In Python 3.0 this would return "secret" instead of raising TypeError.
> This could be worked around using rewriting but it would make
> CapPython more complex and it would be harder to have
> CapPython-verified and non-CapPython-verified code interact securely.
> I've put some more background on this blog post:
> http://lackingrhoticity.blogspot.com/2008/09/cappython-unbound-methods-and-python-30.html
> Mark
> _______________________________________________
> e-lang mailing list
> e-lang at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/e-lang

Americium Dream Documents
"(real opportunity starts with real documentation)
http://amerdreamdocs.tripod.com/ http://www.angelfire.com/psy/dr.addn/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/e-lang/attachments/20080914/951b77ee/attachment.html 

More information about the e-lang mailing list