On 10/20/2012 10:24 AM, Andrea Griffini wrote:
> On Thu, Oct 18, 2012 at 5:41 PM, Georg Brandl wrote:
>> On 10/18/2012 03:16 PM, Daniel Holth wrote:
>>> On Thu, Oct 11, 2012 at 1:36 PM, Vinay Sajip
>>> wrote:
Daniel Holth gmail.com> writes:
> How does this compare to the markerlib
On Thu, Oct 18, 2012 at 5:41 PM, Georg Brandl wrote:
> On 10/18/2012 03:16 PM, Daniel Holth wrote:
>> On Thu, Oct 11, 2012 at 1:36 PM, Vinay Sajip wrote:
>>> Daniel Holth gmail.com> writes:
>>>
How does this compare to the markerlib approach? In markerlib you just
make sure all the AST
On 10/18/2012 03:16 PM, Daniel Holth wrote:
> On Thu, Oct 11, 2012 at 1:36 PM, Vinay Sajip wrote:
>> Daniel Holth gmail.com> writes:
>>
>>> How does this compare to the markerlib approach? In markerlib you just
>>> make sure all the AST nodes are in a set of allowed nodes, currently
>>> (Compare,
On Thu, Oct 11, 2012 at 1:36 PM, Vinay Sajip wrote:
> Daniel Holth gmail.com> writes:
>
>> How does this compare to the markerlib approach? In markerlib you just
>> make sure all the AST nodes are in a set of allowed nodes, currently
>> (Compare, BoolOp, Attribute, Name, Load, Str, cmpop, boolop)
2012/10/11 Vinay Sajip :
> Benjamin Peterson python.org> writes:
>
>>
>> With this operations, you can still cause a lot of trouble.
>>
>
> Perhaps; I am hoping that some more specific information (about the kind of
> trouble this can cause) will emerge. Hence the request for review.
For example,
Am 11.10.2012 20:13, schrieb Serhiy Storchaka:
> On 11.10.12 19:06, Vinay Sajip wrote:
>> Function calls are not allowed in expressions, but the following are:
>
> Are properties allowed?
Yes, since attribute access also means properties.
This doesn't have to be a problem, since the objects on w
On 11.10.12 19:06, Vinay Sajip wrote:
Function calls are not allowed in expressions, but the following are:
Are properties allowed?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
ht
On 11.10.12 19:34, Benjamin Peterson wrote:
With this operations, you can still cause a lot of trouble.
Agree. Simple example: 9**9**9.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
> ISTM there is a space for a limited evaluator that's less limiting than
> literal_eval(). I do realise that this type of sandboxing is not easy to
> achieve,
> and I'm not aiming to advance the state of the art here - I just want to close
> the issue in the best way I can.
It is certainly a use
Daniel Holth gmail.com> writes:
> How does this compare to the markerlib approach? In markerlib you just
> make sure all the AST nodes are in a set of allowed nodes, currently
> (Compare, BoolOp, Attribute, Name, Load, Str, cmpop, boolop), and then
> use the normal eval(). Is one way more secure
Benjamin Peterson python.org> writes:
>
> With this operations, you can still cause a lot of trouble.
>
Perhaps; I am hoping that some more specific information (about the kind of
trouble this can cause) will emerge. Hence the request for review.
> What exactly are you trying to prevent?
The
On Thu, Oct 11, 2012 at 12:34 PM, Benjamin Peterson wrote:
> 2012/10/11 Vinay Sajip :
>> In response to http://bugs.python.org/issue15452, I've created an improved
>> evaluator in the ast module in my sandbox repo. The evaluator supports
>> lookup of
>> names in a supplied namespace. The basic in
2012/10/11 Vinay Sajip :
> In response to http://bugs.python.org/issue15452, I've created an improved
> evaluator in the ast module in my sandbox repo. The evaluator supports lookup
> of
> names in a supplied namespace. The basic interface is
>
> def lookup_eval(source_string_or_ast_node, namespac
In response to http://bugs.python.org/issue15452, I've created an improved
evaluator in the ast module in my sandbox repo. The evaluator supports lookup of
names in a supplied namespace. The basic interface is
def lookup_eval(source_string_or_ast_node, namespace, allow_imports=False):
# perform
14 matches
Mail list logo
