Mark Janssen writes:
Since there's no way (even theoretical way) to completely secure anything
(remember the DVD protection wars?), there's no way there should be any
liability if reasonable diligence is performed to provide security where
expected (which is probably calculable to some
I think you should provide stronger arguments in each case why the
data needs to be truly immutable or read-only, rather than just using
a convention or an advisory API (like __private can be circumvented
but clearly indicates intent to the reader).
I only know one use case for truly
Problem: if you implement a frozendict type inheriting from dict in
Python, it is still possible to call dict methods (e.g.
dict.__setitem__()). To fix this issue, pysandbox removes all dict
methods modifying the dict: __setitem__, __delitem__, pop, etc. This
is a problem because untrusted
Il 01 marzo 2012 02:45, Raymond Hettinger
raymond.hettin...@gmail.com ha scritto:
On Feb 29, 2012, at 4:23 PM, Victor Stinner wrote:
One of my colleagues implemented recently its own frozendict class
(which the frozendict name ;-)
I write new collection classes all the time.
That doesn't
On Wednesday 29 February 2012 20:17:05 Raymond Hettinger wrote:
On Feb 27, 2012, at 10:53 AM, Victor Stinner wrote:
A frozendict type is a common request from users and there are various
implementations.
ISTM, this request is never from someone who has a use case.
Instead, it almost always
The main idea of pysandbox is to reuse most of CPython but hide
dangerous functions and run untrusted code in a separated namespace.
The problem is to create the sandbox and ensure that it is not
possible to escape from this sandbox. pysandbox is still a
proof-of-concept, even if it works
Actually I find fronzendict concept quite useful. We also have an
implementation in our framework, and we use it, for instance, in
http request object, for parsed arguments and parsed forms, which
values shouldn't be ever modified once parsed.
Of course everybody can live without it, but given
A builtin frozendict type compatible with the PyDict C API is very
convinient for pysandbox because using this type for core features
like builtins requires very few modification. For example, use
frozendict for __builtins__ only requires to modify 3 lines in
frameobject.c.
See the
Here are my real-world use cases. Not for security, but for safety and
performance reasons (I've built by own RODict and ROList modeled after
dictproxy):
- Global, but immutable containers, e.g. as class members
I attached type_final.patch to the issue #14162 to demonstrate how
frozendict
On Thursday 01 March 2012 14:07:10 Victor Stinner wrote:
Here are my real-world use cases. Not for security, but for safety and
performance reasons (I've built by own RODict and ROList modeled after
dictproxy):
- Global, but immutable containers, e.g. as class members
I attached
On Thu, Mar 1, 2012 at 7:29 PM, André Malo n...@perlig.de wrote:
- Caching. My data container objects (say, resultsets from a db or something)
usually inherit from list or dict (sometimes also set) and are cached
heavily. In order to ensure that they are not modified (accidentially), I
have
01.03.12 11:11, Victor Stinner написав(ла):
You can redefine dict.__setitem__.
Ah? It doesn't work here.
dict.__setitem__=lambda key, value: None
Traceback (most recent call last):
File stdin, line 1, inmodule
TypeError: can't set attributes of built-in/extension type 'dict'
Hmm, yes,
On 1 March 2012 12:37, Yury Selivanov yselivanov...@gmail.com wrote:
Actually I find fronzendict concept quite useful. We also have an
implementation in our framework, and we use it, for instance, in
http request object, for parsed arguments and parsed forms, which
values shouldn't be ever
01.03.12 11:29, André Malo написав(ла):
- Caching. My data container objects (say, resultsets from a db or something)
usually inherit from list or dict (sometimes also set) and are cached
heavily. In order to ensure that they are not modified (accidentially), I
have to choices: deepcopy
On Thursday 01 March 2012 15:17:35 Serhiy Storchaka wrote:
01.03.12 11:29, André Malo написав(ла):
- Caching. My data container objects (say, resultsets from a db or
something) usually inherit from list or dict (sometimes also set) and are
cached heavily. In order to ensure that they are
But I will try to suggest another approach. `frozendict` inherits from
`dict`, but data is not stored in the parent, but in the internal
dictionary. And even if dict.__setitem__ is used, it will have no visible
effect.
class frozendict(dict):
def __init__(self, values={}):
Here are my real-world use cases. Not for security, but for safety and
performance reasons (I've built by own RODict and ROList modeled after
dictproxy):
- Global, but immutable containers, e.g. as class members
I attached type_final.patch to the issue #14162 to demonstrate how
On Thursday 01 March 2012 15:54:01 Victor Stinner wrote:
I'm not sure about your final types. I'm using __slots__ = () for such
things
You can still replace an attribute value if a class defines __slots__:
class A:
... __slots__=('x',)
... x = 1
...
A.x=2
A.x
2
Ah, ok, I
On Thu, Mar 1, 2012 at 2:01 AM, Victor Stinner
victor.stin...@haypocalc.com wrote:
The main idea of pysandbox is to reuse most of CPython but hide
dangerous functions and run untrusted code in a separated namespace.
The problem is to create the sandbox and ensure that it is not
possible to
In App Engine's case, an attacker who broke out of the sandbox would have
access to the inside of Google's datacenter, which would obviously be
bad -- that's why Google has developed its own sandboxing
technologies.
This is not specific to Google: if an attacker breaks a sandbox,
he/she has
01.03.12 16:47, André Malo написав(ла):
On Thursday 01 March 2012 15:17:35 Serhiy Storchaka wrote:
This is the first rational use of frozendict that I see. However, a deep
copy is still necessary to create the frozendict. For this case, I
believe, would be better to freeze dict inplace and
On 1 March 2012 17:44, Victor Stinner victor.stin...@gmail.com wrote:
I challenge anyone to try to break pysandbox!
Can you explain precisely how a frozendict will help pysandbox? Then
I'll be able to beat this challenge :-)
Paul.
___
Python-Dev
On Thu, Mar 1, 2012 at 9:44 AM, Victor Stinner victor.stin...@gmail.com wrote:
frozendict would help pysandbox but also any security Python module,
not security, but also (many) other use cases ;-)
Well, let's focus on the other use cases, because to me the sandbox
use case is too controversial
I challenge anyone to try to break pysandbox!
Can you explain precisely how a frozendict will help pysandbox? Then
I'll be able to beat this challenge :-)
See this email:
http://mail.python.org/pipermail/python-dev/2012-February/117011.html
The issue #14162 has also two patches: one to make
* Serhiy Storchaka wrote:
01.03.12 16:47, André Malo написав(ла):
On Thursday 01 March 2012 15:17:35 Serhiy Storchaka wrote:
This is the first rational use of frozendict that I see. However, a
deep copy is still necessary to create the frozendict. For this case,
I believe, would be
* Guido van Rossum wrote:
On Thu, Mar 1, 2012 at 9:44 AM, Victor Stinner victor.stin...@gmail.com
wrote:
frozendict would help pysandbox but also any security Python module,
not security, but also (many) other use cases ;-)
Well, let's focus on the other use cases, because to me the
On Thu, Mar 1, 2012 at 12:35 PM, André Malo n...@perlig.de wrote:
* Guido van Rossum wrote:
On Thu, Mar 1, 2012 at 9:44 AM, Victor Stinner victor.stin...@gmail.com
wrote:
frozendict would help pysandbox but also any security Python module,
not security, but also (many) other use cases ;-)
On Thu, Mar 1, 2012 at 10:00 AM, Guido van Rossum gu...@python.org wrote:
I do know that I don't feel comfortable having a sandbox in the Python
standard library or even recommending a 3rd party sandboxing solution
-- if someone uses the sandbox to protect a critical resource, and a
hacker
Le 01/03/2012 19:07, Guido van Rossum a écrit :
What other use cases are there?
frozendict could be used to implement read-only types: it is not
possible to add or remove an attribute or set an attribute value, but
attribute value can be a mutable object. Example of an enum with my
On Thu, Mar 1, 2012 at 4:39 PM, Victor Stinner victor.stin...@gmail.com wrote:
Le 01/03/2012 19:07, Guido van Rossum a écrit :
What other use cases are there?
frozendict could be used to implement read-only types: it is not possible
to add or remove an attribute or set an attribute value,
On Thu, 01 Mar 2012 16:50:06 -0800, Guido van Rossum gu...@python.org wrote:
On Thu, Mar 1, 2012 at 4:39 PM, Victor Stinner victor.stin...@gmail.com
wrote:
frozendict could be used to implement read-only types: it is not possible
to add or remove an attribute or set an attribute value, but
On Fri, Mar 2, 2012 at 11:50 AM, R. David Murray rdmur...@bitdance.com wrote:
+1. Except in very limited circumstances (such as a security sandbox)
I would *much* rather have the code I'm interacting with use advisory
means rather than preventing me from being a consenting adult. (Having to
On 2012-03-01, at 7:50 PM, Guido van Rossum wrote:
I think you should provide stronger arguments in each case why the
data needs to be truly immutable or read-only, rather than just using
a convention or an advisory API (like __private can be circumvented
but clearly indicates intent to the
On Thu, Mar 1, 2012 at 6:13 PM, Yury Selivanov yselivanov...@gmail.com wrote:
On 2012-03-01, at 7:50 PM, Guido van Rossum wrote:
I think you should provide stronger arguments in each case why the
data needs to be truly immutable or read-only, rather than just using
a convention or an advisory
On 2012-03-01, at 9:31 PM, Guido van Rossum wrote:
That sounds *very* far-fetched. You're pretty much designing a new
language variant. It's not an argument for burdening the original
Yeah, that's what we do ;)
You should be able to prototype what you want using an advisory
subclass (if you
On Feb 27, 2012, at 10:53 AM, Victor Stinner wrote:
A frozendict type is a common request from users and there are various
implementations.
ISTM, this request is never from someone who has a use case.
Instead, it almost always comes from completers, people
who see that we have a frozenset
The frozenset type covers a niche case that is nice-to-have but
*rarely* used. Many experienced Python users simply forget
that we have a frozenset type. We don't get bug reports or
feature requests about the type. When I do Python consulting
work, I never see it in a client's codebase.
On 29 February 2012 19:17, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
From this experience, I conclude that adding a frozendict type
would be a total waste (except that it would inspire more people
to request frozen variante of other containers).
It would (apparently) help Victor to
On Thu, Mar 1, 2012 at 7:08 AM, Paul Moore p.f.mo...@gmail.com wrote:
As it stands, I don't find the PEP compelling. The hardening use case
might be significant but Victor needs to spell it out if it's to make
a difference.
+1
Avoiding-usenet-nod-syndrome'ly,
Nick.
--
Nick Coghlan |
On Thu, Mar 1, 2012 at 8:08 AM, Paul Moore p.f.mo...@gmail.com wrote:
It would (apparently) help Victor to fix issues in his pysandbox
project. I don't know if a secure Python sandbox is an important
enough concept to warrant core changes to make it possible.
If a secure Python sandbox had
On Feb 29, 2012, at 1:08 PM, Paul Moore wrote:
As it stands, I don't find the PEP compelling. The hardening use case
might be significant but Victor needs to spell it out if it's to make
a difference.
If his sandboxing project needs it, the type need not be public.
It can join dictproxy and
It would (apparently) help Victor to fix issues in his pysandbox
project. I don't know if a secure Python sandbox is an important
enough concept to warrant core changes to make it possible.
Ok, let's talk about sandboxing and security.
The main idea of pysandbox is to reuse most of CPython
On Thu, 01 Mar 2012 10:13:01 +1100, Chris Angelico ros...@gmail.com wrote:
On Thu, Mar 1, 2012 at 8:08 AM, Paul Moore p.f.mo...@gmail.com wrote:
It would (apparently) help Victor to fix issues in his pysandbox
project. I don't know if a secure Python sandbox is an important
enough concept
On Feb 29, 2012, at 3:52 PM, Victor Stinner wrote:
I don't know if hardening Python is a compelling argument to add a new
builtin type.
It isn't.
Builtins are for general purpose use.
It is not something most people should use;
however, if it is a builtin, people will be drawn
to
A frozendict type is a common request from users and there are various
implementations.
ISTM, this request is never from someone who has a use case.
One of my colleagues implemented recently its own frozendict class
(which the frozendict name ;-)). He tries to implement something
like the PEP
Raymond Hettinger wrote:
On Feb 29, 2012, at 3:52 PM, Victor Stinner wrote:
I don't know if hardening Python is a compelling argument to add a new
builtin type.
It isn't.
Builtins are for general purpose use.
It is not something most people should use;
however, if it is a builtin, people
Raymond Hettinger wrote:
On Feb 27, 2012, at 10:53 AM, Victor Stinner wrote:
A frozendict type is a common request from users and there are various
implementations.
ISTM, this request is never from someone who has a use case.
Instead, it almost always comes from completers, people
who see
On Feb 29, 2012, at 4:23 PM, Victor Stinner wrote:
One of my colleagues implemented recently its own frozendict class
(which the frozendict name ;-)
I write new collection classes all the time.
That doesn't mean they warrant inclusion in the library or builtins.
There is a use case for
On Wed, Feb 29, 2012 at 3:52 PM, Victor Stinner
victor.stin...@haypocalc.com wrote:
It would (apparently) help Victor to fix issues in his pysandbox
project. I don't know if a secure Python sandbox is an important
enough concept to warrant core changes to make it possible.
Ok, let's talk
On 01.03.2012 02:45, Raymond Hettinger wrote:
On Feb 29, 2012, at 4:23 PM, Victor Stinner wrote:
One of my colleagues implemented recently its own frozendict class
(which the frozendict name ;-)
I write new collection classes all the time.
That doesn't mean they warrant inclusion in the
01.03.12 01:52, Victor Stinner написав(ла):
Problem: if you implement a frozendict type inheriting from dict in
Python, it is still possible to call dict methods (e.g.
dict.__setitem__()). To fix this issue, pysandbox removes all dict
methods modifying the dict: __setitem__, __delitem__, pop,
On Mon, Feb 27, 2012 at 19:53, Victor Stinner
victor.stin...@haypocalc.com wrote:
A frozendict type is a common request from users and there are various
implementations. There are two main Python implementations:
Perhaps this should also detail why namedtuple is not a viable alternative.
Victor Stinner wrote:
The blacklist implementation has a major issue: it is still possible
to call write methods of the dict class (e.g. dict.set(my_frozendict,
key, value)).
It is also possible to use ctypes and violate even more invariants.
For most purposes, this falls under consenting
A frozendict type is a common request from users and there are various
implementations. There are two main Python implementations:
Perhaps this should also detail why namedtuple is not a viable alternative.
It doesn't have the same API. Example: frozendict[key] vs
namedtuple.attr
I think you need to elaborate on your use cases further, ...
A frozendict can be used as a member of a set or as a key in a dictionary.
For example, frozendict is indirectly needed when you want to use an
object as a key of a dict, whereas one attribute of this object is a
dict. Use a
On Tue, 28 Feb 2012 12:45:54 +0100
Victor Stinner victor.stin...@haypocalc.com wrote:
I think you need to elaborate on your use cases further, ...
A frozendict can be used as a member of a set or as a key in a dictionary.
For example, frozendict is indirectly needed when you want to use an
Antoine Pitrou wrote:
On Tue, 28 Feb 2012 12:45:54 +0100
Victor Stinner victor.stin...@haypocalc.com wrote:
I think you need to elaborate on your use cases further, ...
A frozendict can be used as a member of a set or as a key in a dictionary.
For example, frozendict is indirectly needed when
On 28 February 2012 12:07, Mark Shannon m...@hotpy.org wrote:
frozendict helps also in threading and multiprocessing.
How so?
Inter process/task communication requires copying. Inter/intra thread
communication uses reference semantics. To ensure these are the same,
the objects used in
A frozendict can be used as a member of a set or as a key in a dictionary.
For example, frozendict is indirectly needed when you want to use an
object as a key of a dict, whereas one attribute of this object is a
dict.
It isn't. You just have to define __hash__ correctly.
Define __hash__
Updated patch and more justifications.
New patch:
- dict doesn't inherit from frozendict anymore
- frozendict is a subclass of collections.abc.Mutable
- more tests
* frozendict.__hash__ computes hash(frozenset(self.items())) and
caches the result is its private hash attribute
On Tue, 28 Feb 2012 12:07:32 +
Mark Shannon m...@hotpy.org wrote:
Antoine Pitrou wrote:
On Tue, 28 Feb 2012 12:45:54 +0100
Victor Stinner victor.stin...@haypocalc.com wrote:
I think you need to elaborate on your use cases further, ...
A frozendict can be used as a member of a set or
Hi,
I don't know if an implementation of the frozendict actually exists,
but if anyone is planning on writing one then can I suggest that they
take a look at my new dict implementation:
http://bugs.python.org/issue13903
https://bitbucket.org/markshannon/cpython_new_dict/
Making dicts immutable
On Tue, 28 Feb 2012 13:14:15 +0100
Victor Stinner victor.stin...@haypocalc.com wrote:
See also the PEP 351.
I read the PEP and the email explaining why it was rejected.
I think you should write a separate PEP and explain the use cases
clearly.
cheers
Antoine.
Victor Stinner wrote:
See also the PEP 351.
I read the PEP and the email explaining why it was rejected.
Just to be clear: the PEP 351 tries to freeze an object, try to
convert a mutable or immutable object to an immutable object. Whereas
my frozendict proposition doesn't convert
M.-A. Lemburg wrote:
Victor Stinner wrote:
See also the PEP 351.
I read the PEP and the email explaining why it was rejected.
Just to be clear: the PEP 351 tries to freeze an object, try to
convert a mutable or immutable object to an immutable object. Whereas
my frozendict proposition doesn't
* frozendict values must be immutable, as dict keys
Why? That may be useful, but an immutable dict whose values
might mutate is also useful; by forcing that choice, it starts
to feel too specialized for a builtin.
Hum, I realized that calling hash(my_frozendict) on a frozendict
instance is
Victor Stinner wrote:
* frozendict values must be immutable, as dict keys
Why? That may be useful, but an immutable dict whose values
might mutate is also useful; by forcing that choice, it starts
to feel too specialized for a builtin.
Hum, I realized that calling hash(my_frozendict) on a
Steven D'Aprano wrote:
M.-A. Lemburg wrote:
Victor Stinner wrote:
See also the PEP 351.
I read the PEP and the email explaining why it was rejected.
Just to be clear: the PEP 351 tries to freeze an object, try to
convert a mutable or immutable object to an immutable object. Whereas
my
Rationale
=
A frozendict type is a common request from users and there are various
implementations. There are two main Python implementations:
* blacklist: frozendict inheriting from dict and overriding methods
to raise an exception when trying to modify the frozendict
* whitelist:
On 2012-02-27, at 19:53 , Victor Stinner wrote:
Rationale
=
A frozendict type is a common request from users and there are various
implementations. There are two main Python implementations:
* blacklist: frozendict inheriting from dict and overriding methods
to raise an
This may be an issue at the C level (I'm not sure), but since this would
be a Python 3-only collection, user code (in Python) should/would
generally be using abstract base classes, so type-checking would not
be an issue (as in Python code performing `isinstance(a, dict)` checks
naturally
In http://mail.python.org/pipermail/python-dev/2012-February/116955.html
Victor Stinner proposed:
The blacklist implementation has a major issue: it is still possible
to call write methods of the dict class (e.g. dict.set(my_frozendict,
key, value)).
It is also possible to use ctypes and
The blacklist implementation has a major issue: it is still possible
to call write methods of the dict class (e.g. dict.set(my_frozendict,
key, value)).
It is also possible to use ctypes and violate even more invariants.
For most purposes, this falls under consenting adults.
My primary
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/27/2012 06:34 PM, Victor Stinner wrote:
tuple and frozenset can only contain immutables values.
Tuples can contain mutables::
$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56)
[GCC 4.4.3] on linux2
Type help, copyright, credits
On Tue, Feb 28, 2012 at 9:34 AM, Victor Stinner
victor.stin...@gmail.com wrote:
The blacklist implementation has a major issue: it is still possible
to call write methods of the dict class (e.g. dict.set(my_frozendict,
key, value)).
It is also possible to use ctypes and violate even more
Nick Coghlan ncoghlan at gmail.com writes:
I'm pretty sure the PyPy jit can already pick up and optimise cases
where a dict goes read-only (i.e. stops being modified).
No, it doesn't. We handle cases like a type's dict, or a module's dict,
by having them use a different internal implementation
76 matches
Mail list logo
