Victor Stinner 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 the hash collision issue.
On Sat, Jan 21, 2012 at 7:50 AM, Matthew Woodcraft
wrote:
> Victor Stinner 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
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) miscompi
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
On Sat, 21 Jan 2012 21:51:43 +0100
gregory.p.smith wrote:
> http://hg.python.org/cpython/rev/d01fecadf3ea
> changeset: 74561:d01fecadf3ea
> branch: 3.2
> parent: 74558:03e61104f7a2
> user:Gregory P. Smith
> date:Sat Jan 21 12:31:25 2012 -0800
> summary:
> Avoid the c
2012/1/21 Antoine Pitrou :
> On Sat, 21 Jan 2012 21:51:43 +0100
> gregory.p.smith wrote:
>> http://hg.python.org/cpython/rev/d01fecadf3ea
>> changeset: 74561:d01fecadf3ea
>> branch: 3.2
>> parent: 74558:03e61104f7a2
>> user: Gregory P. Smith
>> date: Sat Jan 21 12:31:25
Benjamin Peterson 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 stop usin
2012/1/21 Stefan Krah :
> Benjamin Peterson 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 war
On Sat, 21 Jan 2012 23:39:41 +0100
gregory.p.smith wrote:
> http://hg.python.org/cpython/rev/61aa484a3e54
> changeset: 74563:61aa484a3e54
> branch: 3.2
> parent: 74561:d01fecadf3ea
> user:Gregory P. Smith
> date:Sat Jan 21 14:01:08 2012 -0800
> summary:
> Fixes issue
On Sat, Jan 21, 2012 at 2:33 PM, Stefan Krah wrote:
> Benjamin Peterson 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, ./conf
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 whethe
On Sat, Jan 21, 2012 at 2:52 PM, Antoine Pitrou wrote:
> On Sat, 21 Jan 2012 23:39:41 +0100
> gregory.p.smith wrote:
>> http://hg.python.org/cpython/rev/61aa484a3e54
>> changeset: 74563:61aa484a3e54
>> branch: 3.2
>> parent: 74561:d01fecadf3ea
>> user: Gregory P. Smith
>> date
2012/1/21 Gregory P. Smith :
> On Sat, Jan 21, 2012 at 2:33 PM, Stefan Krah wrote:
>> Benjamin Peterson 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
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 wi
2012/1/21 gregory.p.smith :
...
> +/* 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 different line from the signa
On Sat, Jan 21, 2012 at 4:19 PM, Jared Grubb 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 value for
> the h
Paul McMillan wrote:
On Sat, Jan 21, 2012 at 4:19 PM, Jared Grubb 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
Benjamin Peterson writes:
> 2012/1/21 Stefan Krah :
> > 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 may be del
> 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
