Victor Stinner victor.stin...@haypocalc.com wrote:
I propose to solve the hash collision vulnerability by counting
collisions [...]
We now know all issues of the randomized hash solution, and I
think that there are more drawbacks than advantages. IMO the
randomized hash is overkill to fix
On Sat, Jan 21, 2012 at 7:50 AM, Matthew Woodcraft
matt...@woodcraft.me.uk wrote:
Victor Stinner victor.stin...@haypocalc.com wrote:
I propose to solve the hash collision vulnerability by counting
collisions [...]
We now know all issues of the randomized hash solution, and I
think that
Am Freitag, 20. Januar 2012 um 23:40 schrieb Vijay 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) miscompiles Python:
On Fri, 2012-01-20 at 16:55 +0100, Frank Sievertsen wrote:
Hello,
I still see at least two ways to create a DOS attack even with the
collison-counting-patch.
[snip description of two types of attack on the collision counting
approach]
What to do now?
I think it's not smart to reduce the
On Sat, 21 Jan 2012 21:51:43 +0100
gregory.p.smith python-check...@python.org wrote:
http://hg.python.org/cpython/rev/d01fecadf3ea
changeset: 74561:d01fecadf3ea
branch: 3.2
parent: 74558:03e61104f7a2
user:Gregory P. Smith g...@krypto.org
date:Sat Jan 21 12:31:25
2012/1/21 Antoine Pitrou solip...@pitrou.net:
On Sat, 21 Jan 2012 21:51:43 +0100
gregory.p.smith python-check...@python.org wrote:
http://hg.python.org/cpython/rev/d01fecadf3ea
changeset: 74561:d01fecadf3ea
branch: 3.2
parent: 74558:03e61104f7a2
user: Gregory P. Smith
Benjamin Peterson benja...@python.org wrote:
Can't that give you another warning about the ssize_t being truncated to
int?
How about the following instead?
(void) write(...);
Also, if you use a recent enough version of gcc, ./configure will
disable the warning. I would prefer if
2012/1/21 Stefan Krah ste...@bytereef.org:
Benjamin Peterson benja...@python.org wrote:
Can't that give you another warning about the ssize_t being truncated to
int?
How about the following instead?
(void) write(...);
Also, if you use a recent enough version of gcc, ./configure will
On Sat, 21 Jan 2012 23:39:41 +0100
gregory.p.smith python-check...@python.org wrote:
http://hg.python.org/cpython/rev/61aa484a3e54
changeset: 74563:61aa484a3e54
branch: 3.2
parent: 74561:d01fecadf3ea
user:Gregory P. Smith g...@krypto.org
date:Sat Jan 21 14:01:08
On Sat, Jan 21, 2012 at 2:33 PM, Stefan Krah ste...@bytereef.org wrote:
Benjamin Peterson benja...@python.org wrote:
Can't that give you another warning about the ssize_t being truncated to
int?
How about the following instead?
(void) write(...);
Also, if you use a recent enough
Glyph wrote:
Yes, but you /can/ look at a 'yield' and conclude that you /might/ need
a lock, and that you have to think about it.
My concern is that you will end up with vastly more 'yield from's
than places that require locks, so most of them are just noise.
If you bite your nails over
On Sat, Jan 21, 2012 at 2:52 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 21 Jan 2012 23:39:41 +0100
gregory.p.smith python-check...@python.org wrote:
http://hg.python.org/cpython/rev/61aa484a3e54
changeset: 74563:61aa484a3e54
branch: 3.2
parent: 74561:d01fecadf3ea
2012/1/21 Gregory P. Smith g...@krypto.org:
On Sat, Jan 21, 2012 at 2:33 PM, Stefan Krah ste...@bytereef.org wrote:
Benjamin Peterson benja...@python.org wrote:
Can't that give you another warning about the ssize_t being truncated to
int?
How about the following instead?
(void)
On 20 Jan 2012, at 10:49, Brett Cannon wrote:
Why can't we have our cake and eat it too?
Can we do hash randomization in 3.3 and use the hash count solution for
bugfix releases? That way we get a basic fix into the bugfix releases that
won't break people's code (hopefully) but we go with a
2012/1/21 gregory.p.smith python-check...@python.org:
...
+/* Convert ASCII to a positive int, no libc call. no overflow. -1 on error.
*/
Is no libc call important?
+static int _pos_int_from_ascii(char *name)
To be consistent with the rest of posixmodule.c, static int should
be on a
On Sat, Jan 21, 2012 at 4:19 PM, Jared Grubb jared.gr...@gmail.com wrote:
I agree; it sounds really odd to throw an exception since nothing is actually
wrong and there's nothing the caller would do about it to recover anyway.
Rather than throwing an exception, maybe you just reseed the random
Paul McMillan wrote:
On Sat, Jan 21, 2012 at 4:19 PM, Jared Grubb jared.gr...@gmail.com wrote:
I agree; it sounds really odd to throw an exception since nothing is actually
wrong and there's nothing the caller would do about it to recover anyway.
Rather than throwing an exception, maybe you
Benjamin Peterson writes:
2012/1/21 Stefan Krah ste...@bytereef.org:
Do you mean (void)write(...)? Many people think this is good practice,
since it indicates to the reader that the return value is deliberately
ignored.
Not doing anything with it seems fairly deliberate to me.
It
My concern is that you will end up with vastly more 'yield from's
than places that require locks, so most of them are just noise.
If you bite your nails over whether a lock is needed every time
you see one, they will cause you a lot more anxiety than they
alleviate.
Not necessarily. The
I may have a terminology problem here. I expect that a random seed must
change every time it is used, otherwise the pseudorandom number generator
using it just returns the same value each time. Should we be talking about a
salt rather than a seed?
You should read the several other threads,
20 matches
Mail list logo
