Re: An object-capability subset of Python

On Wed, Aug 13, 2008 at 7:55 AM, Ben Laurie <[email protected]> wrote:
> On Mon, Aug 11, 2008 at 9:31 PM, Mark Seaborn <mrs-ChQETwBkFSdCgCasaBwmdgC/[email protected]> wrote:
>> I have been investigating the feasibility of creating an
>> object-capability subset of Python, along the lines of Caja and Joe-E.
>> I will call the subset CapPython for now, because the name doesn't
>> seem to have been taken yet. :-)

Also still available: Monty and Pithy ;).


>> Although Python does not provide encapsulation, there is a widely-used
>> naming convention for private attributes of objects: their names start
>> with an underscore.  CapPython proposes to enforce this convention by
>> only allowing private attributes to be accessed through the "self"
>> variable that is bound inside methods.

This is approximately the approach used by the language currently
named "Caja" and about to be renamed "Original-Caja". Because of
JavaScript's insane rules regarding the scoping of "this", we had to
do <http://code.google.com/p/google-caja/wiki/FunctionSpecies> to
maintain this protection, which is too complicated. We're now turning
towards using only Cajita for security, which parallels Brett's
suggestion of using only closures for encapsulation
<http://groups.google.com/group/google-caja-discuss/browse_thread/thread/284935fa0784316d/31e476a985ae8c66?lnk=gst&q=valija#31e476a985ae8c66>.
However, Python, being less insane than JavaScript, may more happily
accommodate the private name approach.


>>  There are more details here:
>> http://lackingrhoticity.blogspot.com/2008/08/introducing-cappython.html
>> along with some less readable notes here:
>> http://plash.beasts.org/wiki/CapPython

I have added CapPython and Ecru to
<http://wiki.erights.org/wiki/Object-capability_languages>. Brett,
your work on securing Python appears there as SecurePython. Is this
the right name?

> I tried to do this years ago. It wasn't well received by the Python
> developers :-)

Given Ecru's Python bridge, this may increase or decrease the desire
for a secure Python. In any case, it's one of a zillion ways the world
has changed since the Python community rejected previous attempts.


>> I suspect that for this to become more useful it would need to become
>> a rewriter rather than a verifier.

With Joe-E, Emily, and Backwater are verifier-only approaches, but
that was workable because these languages are statically typed. W7
didn't need to do rewriting, because Scheme scoping is already so
principled. Even though Python is better behaved than JavaScript, I
suspect you will need to rewrite. But it will be interesting to see
how far you can go with only verification and scope substitution.

-- 
    Cheers,
    --MarkM