Am 20.01.2012 20:05, schrieb Chris Withers:
> On 14/01/2012 16:14, Sandro Tosi wrote:
>> Hello,
>> just a heads-up: documentation for 2.7 branch has been ported to use
>> sphinx 1.0, so now the same syntax can be used for 2.x and 3.x
>> patches, hopefully easying working on both python stacks.
>
>
On Fri, Jan 20, 2012 at 07:05:41PM +, Chris Withers wrote:
>
> That's great news, does that now mean the objects inventory for
> Python 2.7 and Python 3 on python.org now supports referring to
> section headers from 3rd party packages?
Nope. It does not seem to have any relation to that. Woul
On 1/20/2012 7:40 PM, Steven D'Aprano wrote:
Benjamin Peterson wrote:
2012/1/20 Terry Reedy :
Since 'raise' means 're-raise the current error', 'raise as OtherError'
means (clearly to me, anyway) 're-raise the current error as
OtherError'.
That doesn't make any sense. You're changing the exce
Ethan Furman wrote:
The question I have at the moment is: should `raise as` be an error if
no exception is currently being handled?
I think so.
"raise as Spam" essentially means "raise Spam with the context set to None".
That's actually only useful if the context otherwise wouldn't be None,
On Fri, Jan 20, 2012 at 6:33 PM, Steven D'Aprano wrote:
> Guido van Rossum wrote:
>>
>> It should derive from BaseException.
> RuntimeError meets that requirement, and it is an existing exception so
> there are no issues with introducing a new built-in exception to a point
> release.
>
> py> issu
2012/1/20 Steven D'Aprano :
> Guido van Rossum wrote:
>>
>> It should derive from BaseException.
>
>
> RuntimeError meets that requirement, and it is an existing exception so
> there are no issues with introducing a new built-in exception to a point
> release.
>
> py> issubclass(RuntimeError, BaseE
Guido van Rossum wrote:
It should derive from BaseException.
RuntimeError meets that requirement, and it is an existing exception so there
are no issues with introducing a new built-in exception to a point release.
py> issubclass(RuntimeError, BaseException)
True
--
Steven
Terry Reedy wrote:
On 1/20/2012 11:17 AM, Victor Stinner wrote:
There is no perfect solutions, drawbacks of each solution should be
compared.
Amen.
One possible attack that has been described for a collision counting
dict depends on knowing precisely the trigger point. So let
MAXCOLLISIONS
It should derive from BaseException.
--Guido van Rossum (sent from Android phone)
On Jan 20, 2012 4:59 PM, "Steven D'Aprano" wrote:
> Guido van Rossum wrote:
>
>> On Fri, Jan 20, 2012 at 11:51 AM, Donald Stufft
>> **wrote:
>>
>> On Friday, January 20, 2012 at 2:36 PM, Tres Seaver wrote:
>>>
>
Guido van Rossum wrote:
On Fri, Jan 20, 2012 at 11:51 AM, Donald Stufft wrote:
On Friday, January 20, 2012 at 2:36 PM, Tres Seaver wrote:
On 01/20/2012 02:04 PM, Donald Stufft wrote:
Even if a MemoryException is raised I believe that is still a
fundamental change in the documented contract o
Benjamin Peterson wrote:
2012/1/20 Terry Reedy :
Since 'raise' means 're-raise the current error', 'raise as OtherError'
means (clearly to me, anyway) 're-raise the current error as OtherError'.
That doesn't make any sense. You're changing the exception completely
not reraising it.
I expect
2012/1/19 Gregory P. Smith
> str[-1] is not likely to work if you want to maintain ABI compatibility.
> Appending it to the data after the terminating \0 is more likely to be
> possible, but if there is any possibility that existing compiled extension
> modules have somehow inlined code to do al
On Fri, Jan 20, 2012 at 2:35 PM, Frank Sievertsen wrote:
> Am 20.01.2012 16:33, schrieb Guido van Rossum:
>
>> (I'm thinking that the original attack is trivial once the set of 65000
>> colliding keys is public knowledge, which must be only a matter of time.
>
>
>
> I think it's very likely that t
On Fri, Jan 20, 2012 at 2:33 PM, Ben Wolfson wrote:
> On Fri, Jan 20, 2012 at 2:11 PM, Terry Reedy wrote:
>> On 1/20/2012 2:51 PM, Donald Stufft wrote:
>>
>>> I think the counting collision is at best a bandaid and not a proper fix
>>> stemmed from a desire to not break existing applications on a
2012/1/20 Terry Reedy :
> Since 'raise' means 're-raise the current error', 'raise as OtherError'
> means (clearly to me, anyway) 're-raise the current error as OtherError'.
That doesn't make any sense. You're changing the exception completely
not reraising it.
--
Regards,
Benjamin
_
On 2012-01-20, at 4:29 AM, Hynek Schlawack wrote:
> Hello Vijay
>
>
> Am Freitag, 20. Januar 2012 um 00:56 schrieb Vijay N. Majagaonkar:
>
>> I am trying to build python 3 on mac and build failing with following error
>> can somebody help me with this
> It is a known bug that Apple's latest
Am 20.01.2012 16:33, schrieb Guido van Rossum:
(I'm thinking that the original attack is trivial once the set of
65000 colliding keys is public knowledge, which must be only a matter
of time.
I think it's very likely that this will happen soon.
For ASP and PHP there is attack-payload publicl
I believe that either solution has the potential to break existing applications
so to ensure that no applications are broken there will need to be a method of
disabling it. I also believe that to maintain the backwards compatibility that
Python has traditionally had in bug fix releases that eith
Georg Brandl wrote:
Well, the "as" in "raise as" would be very easily overlooked too.
In any case, I don't think the context suppression is the most important
thing about the exception raising, so it doesn't need to stand out...
Good point.
___
Pyth
On Fri, Jan 20, 2012 at 2:11 PM, Terry Reedy wrote:
> On 1/20/2012 2:51 PM, Donald Stufft wrote:
>
>> I think the counting collision is at best a bandaid and not a proper fix
>> stemmed from a desire to not break existing applications on a bugfix
>> release ...
>
> My opinion of counting is better
On 1/20/2012 2:51 PM, Donald Stufft wrote:
I think the counting collision is at best a bandaid and not a proper fix
stemmed from a desire to not break existing applications on a bugfix
release ...
My opinion of counting is better than yours, but even conceding the
theoretical, purity argument
Hi,
2012/1/20 Dr.-Ing. Ingo D. Rullhusen
> using
>
> loc = PyDict_New();
> Py_XDECREF(loc);
>
> or
>
> PyObject *src = Py_CompileString( code.toStdString().c_str(),
> "", Py_single_input );
> Py_XDECREF(src);
>
> results in a "object at blahblah has negative ref count -1" error on
> windows visu
Since 'raise' means 're-raise the current error', 'raise as OtherError'
means (clearly to me, anyway) 're-raise the current error as
OtherError'. This is just what you want to be able to say. Since 'raise'
without a current error results in a TypeError, so should 'raise as
OtherError'. I would
Am 20.01.2012 21:05, schrieb Ethan Furman:
> Benjamin Peterson wrote:
>> 2012/1/20 Ethan Furman :
>>> Summary:
>>>
>>> Exception Chaining is cool, unless you are writing libraries that want to
>>> transform from Exception X to Exception Y as the the previous exception
>>> context is unnecessary, po
Am 20.01.2012 21:08, schrieb Tim Golden:
> On 20/01/2012 19:14, Georg Brandl wrote:
>> Am 20.01.2012 00:54, schrieb "Martin v. Löwis":
I can't help noticing that so far, worries about the workload came mostly
from
people who don't actually bear that load (this is no accusation!), wh
Hello,
using
loc = PyDict_New();
Py_XDECREF(loc);
or
PyObject *src = Py_CompileString( code.toStdString().c_str(),
"", Py_single_input );
Py_XDECREF(src);
results in a "object at blahblah has negative ref count -1" error on
windows visual studio in debug mode. And yes, python is compiled and
l
2012/1/20 Ethan Furman :
> Benjamin Peterson wrote:
>>
>> 2012/1/20 Ethan Furman :
>>>
>>> Summary:
>>>
>>> Exception Chaining is cool, unless you are writing libraries that want to
>>> transform from Exception X to Exception Y as the the previous exception
>>> context is unnecessary, potentially c
Benjamin Peterson wrote:
2012/1/20 Ethan Furman :
Summary:
Exception Chaining is cool, unless you are writing libraries that want to
transform from Exception X to Exception Y as the the previous exception
context is unnecessary, potentially confusing, and cluttery (yup, just made
that word up!)
On 20/01/2012 19:14, Georg Brandl wrote:
Am 20.01.2012 00:54, schrieb "Martin v. Löwis":
I can't help noticing that so far, worries about the workload came mostly from
people who don't actually bear that load (this is no accusation!), while those
that do are the proponents of the PEP...
Ok, so
On Fri, Jan 20, 2012 at 11:51 AM, Donald Stufft wrote:
> On Friday, January 20, 2012 at 2:36 PM, Tres Seaver wrote:
>
> On 01/20/2012 02:04 PM, Donald Stufft wrote:
>
> Even if a MemoryException is raised I believe that is still a
> fundamental change in the documented contract of dictionary API.
Donald Stufft wrote:
Even if a MemoryException is raised I believe that is still a
fundamental change in the documented contract of dictionary API. I don't
believe there is a way to fix this without breaking someones
application. The major differences I see between the two solutions is
that co
On Friday, January 20, 2012 at 2:36 PM, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 01/20/2012 02:04 PM, Donald Stufft wrote:
>
> > Even if a MemoryException is raised I believe that is still a
> > fundamental change in the documented contract of dictionary API
On 14/01/2012 16:14, Sandro Tosi wrote:
Hello,
just a heads-up: documentation for 2.7 branch has been ported to use
sphinx 1.0, so now the same syntax can be used for 2.x and 3.x
patches, hopefully easying working on both python stacks.
That's great news, does that now mean the objects inventor
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/20/2012 02:04 PM, Donald Stufft wrote:
> Even if a MemoryException is raised I believe that is still a
> fundamental change in the documented contract of dictionary API.
How so? Dictionary inserts can *already* raise that error.
> I don't be
On 1/20/2012 10:55 AM, Frank Sievertsen wrote:
Hello,
I still see at least two ways to create a DOS attack even with the
collison-counting-patch.
2. The second attack actually attacks that 1000 allowed string
comparisons are still a lot of work.
First I added 999 strings that collide with a o
Am 20.01.2012 00:54, schrieb "Martin v. Löwis":
>> I can't help noticing that so far, worries about the workload came mostly
>> from
>> people who don't actually bear that load (this is no accusation!), while
>> those
>> that do are the proponents of the PEP...
>
> Ok, so let me add then that I'
On Fri, Jan 20, 2012 at 8:17 AM, Victor Stinner
wrote:
>> So I still think we should ditch the paranoia about dictionary order
>> changing,
>> and fix this without counting.
>
> The randomized hash has other issues:
>
> - its security is based on its secret, whereas it looks to be easy to
> comp
Even if a MemoryException is raised I believe that is still a fundamental
change in the documented contract of dictionary API. I don't believe there is a
way to fix this without breaking someones application. The major differences I
see between the two solutions is that counting will break peopl
On 1/20/2012 11:17 AM, Victor Stinner wrote:
There is no perfect solutions, drawbacks of each solution should be compared.
Amen.
One possible attack that has been described for a collision counting
dict depends on knowing precisely the trigger point. So let
MAXCOLLISIONS either be configure
On Fri, Jan 20, 2012 at 13:15, Guido van Rossum wrote:
> On Fri, Jan 20, 2012 at 5:10 AM, Barry Warsaw wrote:
>
>> On Jan 20, 2012, at 01:50 PM, Victor Stinner wrote:
>>
>> >Counting collision doesn't solve this case, but it doesn't make the
>> >situation worse than before. Raising quickly an ex
Am 20.01.2012 19:15, schrieb Guido van Rossum:
> OTOH, if you change dictionary order and *that* breaks the application,
> then
> the bugs submitted to the application's tracker will be legitimate bugs
> that
> have to be fixed even if nothing else changed.
>
>
> There are lots of
This is the first objection I have seen against collision-counting that
might stand.
On Fri, Jan 20, 2012 at 7:55 AM, Frank Sievertsen wrote:
> Hello,
>
> I still see at least two ways to create a DOS attack even with the
> collison-counting-patch.
>
> I assumed that it's possible to send ~500KB
On Fri, Jan 20, 2012 at 5:20 AM, Barry Warsaw wrote:
> Let's just be clear about it: this exception is new public API. Changing
> dictionary order is not.
>
Not if you raise MemoryError or BaseException.
--
--Guido van Rossum (python.org/~guido)
___
On Fri, Jan 20, 2012 at 5:10 AM, Barry Warsaw wrote:
> On Jan 20, 2012, at 01:50 PM, Victor Stinner wrote:
>
> >Counting collision doesn't solve this case, but it doesn't make the
> >situation worse than before. Raising quickly an exception is better
> >than stalling for minutes, even if I agree
On Fri, Jan 20, 2012 at 1:57 AM, Frank Sievertsen wrote:
> The main issue with that approach is that it allows a new kind of attack.
>
>
> Indeed, I posted another example: http://bugs.python.org/msg151677
>
> This kind of fix can be used in a specific application or maybe in a
> special-purpose
2012/1/20 Ethan Furman :
> Summary:
>
> Exception Chaining is cool, unless you are writing libraries that want to
> transform from Exception X to Exception Y as the the previous exception
> context is unnecessary, potentially confusing, and cluttery (yup, just made
> that word up!).
>
> For all the
On Thu, Jan 19, 2012 at 8:06 PM, Ivan Kozik wrote:
> No, I wasn't happy with termination. I wanted to treat it just like a
> JSON decoding error, and send the appropriate response.
>
So was this attack actually being mounted on your service regularly? I'd
think it would be sufficient to treat i
Summary:
Exception Chaining is cool, unless you are writing libraries that want
to transform from Exception X to Exception Y as the the previous
exception context is unnecessary, potentially confusing, and cluttery
(yup, just made that word up!).
For all the gory details, see http://bugs.pyt
ACTIVITY SUMMARY (2012-01-13 - 2012-01-20)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open3209 ( -1)
closed 22405 (+53)
total 25614 (+52)
Open issues wit
On Fri, Jan 20, 2012 at 01:48, Victor Stinner
wrote:
> - the limit should be configurable: a new function in the sys module
> should be enough. It may be private (or replaced by an environment
> variable?) in stable versions
I'd like to see both. I would like both the programmer and the "user"
t
On Fri, 20 Jan 2012 17:17:24 +0100
Victor Stinner wrote:
> > So I still think we should ditch the paranoia about dictionary order
> > changing,
> > and fix this without counting.
>
> The randomized hash has other issues:
>
> - its security is based on its secret, whereas it looks to be easy to
> So I still think we should ditch the paranoia about dictionary order changing,
> and fix this without counting.
The randomized hash has other issues:
- its security is based on its secret, whereas it looks to be easy to
compute it (see more details in the issue)
- my patch only changes hash(s
> (I'm thinking that the original
> attack is trivial once the set of 65000 colliding keys is public knowledge,
> which must be only a matter of time.)
I have a program able to generate collisions: it takes 1 second to
compute 60,000 colliding strings on a desktop computer. So the
security of the
Hello,
I still see at least two ways to create a DOS attack even with the
collison-counting-patch.
I assumed that it's possible to send ~500KB of payload to the
application.
1. It's fully deterministic which slots the dict will lookup.
Since we don't count slot-collisions, but only hash-value-c
On Fri, Jan 20, 2012 at 1:34 AM, "Martin v. Löwis" wrote:
> > The last solution is very simple: count collision and raise an
> > exception if it hits a limit. The path is something like 10 lines
> > whereas the randomized hash is more close to 500 lines, add a new
> > file, change Visual Studio pr
On Fri, Jan 20, 2012 at 5:32 AM, vinay.sajip wrote:
> http://hg.python.org/cpython/rev/73dad4940b88
> changeset: 74538:73dad4940b88
> branch: 3.1
I thought that the 3.1 branch is in security mode? Is this a security
related fix?
>From my brief scan of the changeset, it doesn't seem to be.
On Fri, 20 Jan 2012 12:57:45 +
Paul Moore wrote:
> On 20 January 2012 03:57, Brian Curtin wrote:
> >> FWIW, it might well be that I can't be available for the 3.3 final
> >> release (I haven't finalized my vacation schedule yet for August).
> >
> > In the interest of not having Windows releas
On Fri, 20 Jan 2012 13:50:18 +0100
Victor Stinner wrote:
> > The main issue with that approach is that it allows a new kind of attack.
> >
> > An attacker now needs to find 1000 colliding keys, and submit them
> > one-by-one into a database. The limit will not trigger, as those are
> > just datab
On Jan 20, 2012, at 03:15 PM, Nick Coghlan wrote:
>With the 1000 collision limit in place, the attacker sends their
>massive request, the affected dict quickly hits the limit, throws an
>unhandled exception which is then caught by the web framework and
>turned into a 500 Error response (or whateve
On Jan 20, 2012, at 03:18 PM, Nick Coghlan wrote:
>On Fri, Jan 20, 2012 at 2:54 PM, Carl Meyer wrote:
>> I don't have the expertise to speak otherwise to the alternatives for
>> fixing the collisions vulnerability, but I don't believe it's accurate
>> to presume that Django would not want to fix
On Jan 20, 2012, at 01:50 PM, Victor Stinner wrote:
>Counting collision doesn't solve this case, but it doesn't make the
>situation worse than before. Raising quickly an exception is better
>than stalling for minutes, even if I agree than it is not the best
>behaviour.
ISTM that adding the possib
On 20 January 2012 03:57, Brian Curtin wrote:
>> FWIW, it might well be that I can't be available for the 3.3 final
>> release (I haven't finalized my vacation schedule yet for August).
>
> In the interest of not having Windows releases depend on one person,
> and having gone through building the
> The main issue with that approach is that it allows a new kind of attack.
>
> An attacker now needs to find 1000 colliding keys, and submit them
> one-by-one into a database. The limit will not trigger, as those are
> just database insertions.
>
> Now, if the applications also as a need to read t
2012/1/20 Frank Sievertsen :
> No, that's not true.
> Whenever a collision happens, other bits are mixed in very fast.
Oh, I didn't know that. So the dict order is only the same if there is
no collision.
Victor
___
Python-Dev mailing list
Python-Dev@pyt
No, that's not true.
Whenever a collision happens, other bits are mixed in very fast.
Frank
Am 20.01.2012 13:08, schrieb Victor Stinner:
I'm surprised we haven't seen bug reports about it from users
of 64-bit Pythons long ago
A Python dictionary only uses the lower bits of a hash value. If you
> I'm surprised we haven't seen bug reports about it from users
> of 64-bit Pythons long ago
A Python dictionary only uses the lower bits of a hash value. If your
dictionary has less than 2**32 items, the dictionary order is exactly
the same on 32 and 64 bits system: hash32(str) & mask == hash64(s
2012/1/20 Ivan Kozik :
> I'd like to point out that an attacker is not limited to sending just
> one dict full of colliding keys. Given a 22ms stall ...
The presented attack produces a stall of at least 30 seconds (5
minutes or more if there is no time limit in the application), not
0.022 second.
On Fri, Jan 20, 2012 at 8:49 PM, Mark Shannon wrote:
> So, don't be afraid to change that hash function :)
Changing it for 3.3 isn't really raising major concerns: the real
concern is with changing it in maintenance and security patches for
earlier releases. Security patches that may break produc
On Fri, Jan 20, 2012 at 5:49 AM, Mark Shannon wrote:
> So, don't be afraid to change that hash function :)
Definitely.
The hash function *has* been changed in the past, and a lot of developers
were schooled in not relying on the iteration order. That's a good thing,
as those developers now writ
Hi,
One of the main sticking points over possible fixes for the
hash-collision security issue seems to be a fear that changing the
iteration order of a dictionary will break backwards compatibility.
The order of iteration has never been specified. In fact not only is it
arbitrary, it cannot
On Fri, Jan 20, 2012 at 7:34 PM, "Martin v. Löwis" wrote:
> The main issue with that approach is that it allows a new kind of attack.
>
> An attacker now needs to find 1000 colliding keys, and submit them
> one-by-one into a database. The limit will not trigger, as those are
> just database insert
The main issue with that approach is that it allows a new kind of attack.
Indeed, I posted another example: http://bugs.python.org/msg151677
This kind of fix can be used in a specific application or maybe in a
special-purpose framework, but not on the level of a general-purpose
language.
Frank
On 01/18/2012 06:55 PM, "Martin v. Löwis" wrote:
I was thinking about adding the field at the end,
Will this make all strings larger, or only those that create dict
collisions? Making all strings larger to fix this issue sounds like a
really bad idea.
Also, would it be acceptable to simply
> The last solution is very simple: count collision and raise an
> exception if it hits a limit. The path is something like 10 lines
> whereas the randomized hash is more close to 500 lines, add a new
> file, change Visual Studio project file, etc. First I thaught that it
> would break more applica
Hello Vijay
Am Freitag, 20. Januar 2012 um 00:56 schrieb Vijay N. Majagaonkar:
> I am trying to build python 3 on mac and build failing with following error
> can somebody help me with this
It is a known bug that Apple's latest gcc-llvm (that comes with Xcode 4.1 by
default as gcc) miscompile
75 matches
Mail list logo
