I can't find it now, but I believe Marc-Andre mentioned that CPython's
list.sort() was vulnerable to attack too, because of its O(n log n)
worst-case behavior.
I wouldn't worry about that, because nobody could stir up anguish
about it by writing a paper ;-)
1. O(n log n) is enormously more forgiv
_PyRLock is not used directly. Instead, no _CRLock is provided, so the
threading.RLock function calls _PyRLock.
It's done this way because green threading libraries may only provide a
greened lock. _CRLock in these contexts would not work: It would block the
entire native thread.
I suspect that i
On 1/5/2012 4:10 PM, Nick Coghlan wrote:
On Fri, Jan 6, 2012 at 8:15 AM, Serhiy Storchaka wrote:
05.01.12 21:14, Glenn Linderman написав(ла):
So, fixing the vulnerable packages could be a sufficient response,
rather than changing the hash function. How to fix? Each of those
above allocates a
Hi Antoine,
On 07/01/12 06:58, Antoine Pitrou wrote:
On Sat, 07 Jan 2012 06:28:00 +1030
Paul Smedley wrote:
I now have a dll and exe - however when it tried to build the modules,
it dies with:
Could not find platform independent libraries
Could not find platform dependent libraries
Consider se
On 6 January 2012 20:25, Mark Shannon wrote:
> Hi,
>
> It seems to me that half the folk discussing this issue want a super-strong,
> resist-all-hypothetical-attacks hash with little regard to performance. The
> other half want no change or a change that will have no observable effect.
> (I may b
On Sat, 07 Jan 2012 06:28:00 +1030
Paul Smedley wrote:
>
> I now have a dll and exe - however when it tried to build the modules,
> it dies with:
> Could not find platform independent libraries
> Could not find platform dependent libraries
> Consider setting $PYTHONHOME to [:]
> Fatal Python e
Hi,
It seems to me that half the folk discussing this issue want a
super-strong, resist-all-hypothetical-attacks hash with little regard to
performance. The other half want no change or a change that will have no
observable effect. (I may be exaggerating a little.)
Can I propose the followi
In http://mail.python.org/pipermail/python-dev/2012-January/115350.html,
Mark Shannon wrote:
> The minimal proposed change of seeding the hash from a global value (a
> single memory read and an addition) will have such a minimal performance
> effect that it will be undetectable even on the most no
Hi All,
On 06/01/12 19:22, Paul Smedley wrote:
I'm a little slow in responding to
http://blog.python.org/2011/05/python-33-to-drop-support-for-os2.html,
but I'm interested in stepping up to help maintain OS/2 support in
Python 3.3 and above.
I've been building Python 2.x for a while, and curren
Thanks for those precisions, but I must admit it doesn't help me much...
Can we drop it? A yes/no answer will do it ;-)
> I'm pretty sure the Python version of RLock is in use in several alternative
> implementations that provide an alternative _thread.lock. I think gevent
> would fall into this c
ACTIVITY SUMMARY (2011-12-30 - 2012-01-06)
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:
open3180 ( +2)
closed 22322 (+34)
total 25502 (+36)
Open issues wit
Hi Paul,
> I'm a little slow in responding to
> http://blog.python.org/2011/05/python-33-to-drop-support-for-os2.html,
> but I'm interested in stepping up to help maintain OS/2 support in
> Python 3.3 and above.
>
> I've been building Python 2.x for a while, and currently have binaries
> of
Using my patch (random-2.patch), the overhead is 0%. I cannot see a
difference with and without my patch.
Numbers:
---
unpatched:
== 3 characters ==
1 loops, best of 3: 459 usec per loop
== 10 characters ==
1 loops, best of 3: 575 usec per loop
== 500 characters ==
1 loops, best of 3: 1.36 msec pe
Glenn Linderman wrote:
On 1/5/2012 5:52 PM, Steven D'Aprano wrote:
At some point, presuming that there is no speed penalty, the behaviour
will surely become not just enabled by default but mandatory. Python
has never promised that hashes must be predictable or consistent, so
apart from backw
On Thu, Jan 5, 2012 at 23:45, Terry Reedy wrote:
> On 1/5/2012 1:51 PM, sandro.tosi wrote:
>>
>> http://hg.python.org/cpython/rev/3353f9747a39
>> changeset: 74282:3353f9747a39
>> branch: 2.7
>
>
>> Doc/whatsnew/2.6.rst | 4 ++--
>
>
> should that have been whatsnew/2.7.rst?
The wording c
Serhiy Storchaka wrote:
06.01.12 02:10, Nick Coghlan написав(ла):
Not a good idea - a lot of the 3rd party tests that depend on dict
ordering are going to be using those modules anyway, so scattering our
solution across half the standard library is needlessly creating
additional work without rea
Hi All,
I'm a little slow in responding to
http://blog.python.org/2011/05/python-33-to-drop-support-for-os2.html,
but I'm interested in stepping up to help maintain OS/2 support in
Python 3.3 and above.
I've been building Python 2.x for a while, and currently have binaries
of 2.6.5 availabl
17 matches
Mail list logo
