On 9/6/06, Ka-Ping Yee [EMAIL PROTECTED]
wrote:
Hi Brett,Here are some comments on your proposal.Sorry this took so long.I apologize if any of these comments are out of date (but also lookforward to your answers to some of the questions, as they'll help
me understand some more of the details of
Hi Brett,
Here are some comments on your proposal. Sorry this took so long.
I apologize if any of these comments are out of date (but also look
forward to your answers to some of the questions, as they'll help
me understand some more of the details of your proposal). Thanks!
Introduction
Phillip J. Eby wrote:
And what about code that needs to pass on a subset of a capability?
With one object == one capability, there is no such
thing as a subset of a capability -- the capabilities
are the atomic units at which you control access. So
you need to make them fine-grained enough
At 09:27 PM 7/23/2006 -0700, Brett Cannon wrote:
On 7/23/06, Phillip J. Eby
mailto:[EMAIL PROTECTED][EMAIL PROTECTED] wrote:
one proxy plus one namechecker equals one capability. In other words,
you could take the restricted interpreter, the proxy mechanism, and the
namechecker and leave most of
On 7/23/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 09:27 PM 7/23/2006 -0700, Brett Cannon wrote:When I say name checker I mean the Zope type that allows you to specify alist of names that are allowed for a given object.This allowing is not
based on identity or code signing or anything like
Brett Cannon wrote:
On 7/23/06, *Armin Rigo* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
Also, I hate to sound self-centered, but I should point out somewhere
that PyPy was started by people who no longer wanted to maintain a fork
of CPython, and preferred to work on building
At 12:50 AM 7/24/2006 -0700, Brett Cannon wrote:
OK, then I need something clarified. If you read
http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/TransitionToSecurityProxieshttp://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/TransitionToSecurityProxies
, it talks
At 12:04 PM 7/25/2006 +1200, Greg Ewing wrote:
Phillip J. Eby wrote:
When I say name checker I mean the Zope type that allows you to
specify a
list of names that are allowed for a given object. This allowing is not
based on identity or code signing or anything like that. It's just a
Phillip J. Eby wrote:
At 12:04 PM 7/25/2006 +1200, Greg Ewing wrote:
Phillip J. Eby wrote:
When I say name checker I mean the Zope type that allows you to specify
a list of names that are allowed for a given object. This allowing is not
based on identity or code signing or anything like that.
Hi Brett,
On Sat, Jul 22, 2006 at 10:33:19AM -0700, Brett Cannon wrote:
Thanks for the link, Armin. Since you guys don't have the import
restrictions the CPython version would have and just have different coding
needs for RPython obviously I can't just do a blind copy. But I will
definitely
Hi David, hi Brett,
On Sun, Jul 23, 2006 at 02:18:48AM +0100, David Hopwood wrote:
If I understand correctly, the proposal is that any incompatible changes
to the language would apply only in sandboxed interpreters. So there is
no reason why support for these couldn't go into the main branch.
On 7/23/06, Armin Rigo [EMAIL PROTECTED] wrote:
Hi David, hi Brett,On Sun, Jul 23, 2006 at 02:18:48AM +0100, David Hopwood wrote: If I understand correctly, the proposal is that any incompatible changes to the language would apply only in sandboxed interpreters. So there is
no reason why support
At 01:00 PM 7/23/2006 -0700, Brett Cannon wrote:
I obviously don't want to change the feel of Python, but if I have to
remove the constructor for code objects to prevent evil bytecode or
__subclasses__() from object to prevent poking around stuff, then so be
it. For this project, security is
Phillip J. Eby wrote:
At 01:00 PM 7/23/2006 -0700, Brett Cannon wrote:
I obviously don't want to change the feel of Python, but if I have to
remove the constructor for code objects to prevent evil bytecode or
__subclasses__() from object to prevent poking around stuff, then so be
it. For
Brett Cannon wrote:
On 7/23/06, Armin Rigo [EMAIL PROTECTED] wrote:
Hi David, hi Brett,
On Sun, Jul 23, 2006 at 02:18:48AM +0100, David Hopwood wrote:
If I understand correctly, the proposal is that any incompatible
changes to the language would apply only in sandboxed interpreters.
So
On 7/23/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 11:07 PM 7/23/2006 +0100, David Hopwood wrote:Phillip J. Eby wrote:[snip]
Brett's securing_python.txt don't refer to or cite Zope in any way, butrather relies on broad and unsupported assertions about what can or can'tbe done with Python.I
Hi Brett,
On Wed, Jul 19, 2006 at 03:35:45PM -0700, Brett Cannon wrote:
I also plan to rewrite the import machinery in pure Python.
http://codespeak.net/svn/pypy/dist/pypy/module/__builtin__/importing.py
A bientot,
Armin
___
Python-Dev mailing list
Re-hi,
On Wed, Jul 19, 2006 at 03:35:45PM -0700, Brett Cannon wrote:
http://svn.python.org/view/python/branches/bcannon-sandboxing/securing_python.txt?rev=50717view=log.
I'm not sure I understand what you propose to fix holes like
constructors and __subclasses__: it seems that you want to
On 7/22/06, Armin Rigo [EMAIL PROTECTED] wrote: Re-hi, On Wed, Jul 19, 2006 at 03:35:45PM -0700, Brett Cannon wrote:
http://svn.python.org/view/python/branches/bcannon-sandboxing/securing_python.txt?rev=50717view=log. I'm not sure I understand what you propose to fix holes like constructors
On 7/22/06, Armin Rigo [EMAIL PROTECTED] wrote:
Hi Brett,On Wed, Jul 19, 2006 at 03:35:45PM -0700, Brett Cannon wrote: I also plan to rewrite the import machinery in pure Python.
http://codespeak.net/svn/pypy/dist/pypy/module/__builtin__/importing.pyThanks for the link, Armin. Since you guys don't
Armin Rigo wrote:
I'm not sure I understand what you propose to fix holes like
constructors and __subclasses__: it seems that you want to remove them
altogether (and e.g. make factory functions instead). That would
completely break all programs, right? I mean, there is no way such
changes
Armin Rigo wrote:
Re-hi,
On Wed, Jul 19, 2006 at 03:35:45PM -0700, Brett Cannon wrote:
http://svn.python.org/view/python/branches/bcannon-sandboxing/securing_python.txt?rev=50717view=log.
I'm not sure I understand what you propose to fix holes like
constructors and __subclasses__: it
Brett Cannon wrote:
Extensible file type handling
-
If the file type handlers are stored in normal Python data
structures as
described above, it becomes feasible to make the import system
extensible to
different file types as well as
That's great. I just read your draft but I have little comments to do
but before let me say that I liked the idea to borrow concepts from E.
I've crossed the E's path in the beginning of this year and I found it
a pot of really nice ideas (for promises and capabilities). Here are
my comments about
Giovanni Bajo [EMAIL PROTECTED] wrote:
This recipe for safe_eval:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/496746
which is otherwise very cute, does not handle this case as well: it tries to
catch and interrupt long-running operations through a secondary thread, but
fails on
Nick Maclaren wrote:
This recipe for safe_eval:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/496746
which is otherwise very cute, does not handle this case as well: it
tries to catch and interrupt long-running operations through a
secondary thread, but fails on a single long
For code objects, their construction is already commonly written as
compile(source).
For type objects, the constructor doesn't let you do anything you can't
already do with a class statement. It doesn't need securing.
For rewriting import.c in Python, the PEP 302 compliant import system API in
On 7/20/06, Giovanni Bajo [EMAIL PROTECTED] wrote:
Brett Cannon wrote: The new doc is named securing_python.txt and can be found through the svn web interface at
http://svn.python.org/view/python/branches/bcannon-sandboxing/securing_python.txt?rev=50717view=log.How do you plan to handle CPU-hogs?
On 7/20/06, Nick Coghlan [EMAIL PROTECTED] wrote:
For code objects, their construction is already commonly written ascompile(source).Right, but some people like to construct directly from bytecode.
For type objects, the constructor doesn't let you do anything you can'talready do with a class
On 7/20/06, Lawrence Oluyede [EMAIL PROTECTED] wrote:
That's great. I just read your draft but I have little comments to dobut before let me say that I liked the idea to borrow concepts from E.I've crossed the E's path in the beginning of this year and I found it
a pot of really nice ideas (for
Brett Cannon wrote:
http://svn.python.org/view/python/branches/bcannon-sandboxing/securing_python.txt?rev=50717view=log
.
How do you plan to handle CPU-hogs? Stuff like execution of a
gigantic integer multiplication.
I don't. =) Protecting the CPU is damn hard to do in any form of
On 7/20/06, Giovanni Bajo [EMAIL PROTECTED] wrote:
Brett Cannon wrote:http://svn.python.org/view/python/branches/bcannon-sandboxing/securing_python.txt?rev=50717view=log
. How do you plan to handle CPU-hogs? Stuff like execution of a gigantic integer multiplication. I don't.=)Protecting the CPU
Should be faster than an IBAC model since certain calls will not need to
check the identity of the caller every time.
But I am not worrying about performance, I am worrying about correctness, so
I did not try to make any performance claims.
Got that.
Nope. Have not started worrying about
After various people suggesting object-capabilities, takling with Mark S. Miller of the E programming language, and the people Mark works with at HP Labs (who have been giving talks every week during this month here at Google on object-capabilities), I have decided to go with object-capabilities
On Wed, 19 Jul 2006, Brett Cannon wrote:
I have decided to go with object-capabilities for
securing interpreters. I have rewritten my design doc from scratch and
deleted the old one. The new doc is named securing_python.txt and can be
found through the svn web interface at
Brett Cannon wrote:
After various people suggesting object-capabilities, takling with Mark
S. Miller of the E programming language, and the people Mark works
with at HP Labs (who have been giving talks every week during this
month here at Google on object-capabilities), I have decided to go
Michael Foord wrote:
Brett Cannon wrote:
After various people suggesting object-capabilities, takling with Mark
S. Miller of the E programming language, and the people Mark works
with at HP Labs (who have been giving talks every week during this
month here at Google on
37 matches
Mail list logo
