> invasive to app code. It seems that this crafted-hash-collision
> vector doesn't have a clean answer like that. There are workarounds,
> but they may not apply to particular codebases.
Yeah. The discussion going on over at python-dev suggests that Python
itself may actually implement support a
On Thu, Dec 29, 2011 at 12:10 PM, Paul McMillan wrote:
...
>> That seems like a simpler workaround than arch upgrade or replacing
>> dict implementation.
>
> This problem has nothing to do with slowloris.
>
> Replacing dict implementation prevents an attacker from producing keys
> which are intent
> Slow Loris can be avoided by putting a proxy capable of buffering
> requests until completion between the app server and the web, right?
Yes, use nginx or similar. Slowloris is generally not a problem when
that is properly configured.
> That seems like a simpler workaround than arch upgrade or
On Thu, Dec 29, 2011 at 8:19 AM, Christophe Pettus wrote:
...
> It's an interesting result, but I'm not sure how much to be worried about it
> in the field. A SlowLoris or similar attack would seem to be far more
> effective and less implementation-dependent.
Slow Loris can be avoided by putti
Thanks
On Thu, Dec 29, 2011 at 11:36 AM, Alex Gaynor wrote:
>
>
> On Thu, Dec 29, 2011 at 10:32 AM, Daniel Sokolowski <
> daniel.sokolow...@klinsight.com> wrote:
>
>> Would someone be so kind and explain why POST variables are stored in
>> hash tables? What is the reasoning behind it? Speed? Or
On Thu, Dec 29, 2011 at 10:32 AM, Daniel Sokolowski <
daniel.sokolow...@klinsight.com> wrote:
> Would someone be so kind and explain why POST variables are stored in hash
> tables? What is the reasoning behind it? Speed? Or is this simply done at
> the Python level when using a dictionary type? Th
Would someone be so kind and explain why POST variables are stored in hash
tables? What is the reasoning behind it? Speed? Or is this simply done at
the Python level when using a dictionary type? Thank you
On Thu, Dec 29, 2011 at 11:19 AM, Christophe Pettus wrote:
>
> On Dec 29, 2011, at 8:12 AM,
On Dec 29, 2011, at 8:12 AM, Daniel Sokolowski wrote:
> So this would effect django because of the CSRF token check --- which
> requires the hash to be regenerated before comparing it yes?
No, the problem is somewhat different. The attacker constructs a POST request
in which the field names a
So this would effect django because of the CSRF token check --- which
requires the hash to be regenerated before comparing it yes?
On Wed, Dec 28, 2011 at 9:26 PM, Luciano Pacheco wrote:
> Hi all,
>
> Have you guys seen this?
> http://www.ocert.org/advisories/ocert-2011-003.html
>
> PDF with som
+1 for Paul's concerns. I think this at least should be opt-in.
It can be also more or less implemented without custom widgets but
using Gregor Müllegger's form-rendering branch (which is not merged but
available as https://github.com/SmileyChris/django-forms app if I
understand it properly) -
Hi folks,
We released an alpha of Django 1.4 on December 22nd. We plan to release a beta
on Feb 2nd and the final version an March 1st. By then, we'd like to fix as
many bugs as possible, starting with those that matter most to you.
You may be familiar with our contributing processes, but in ca
11 matches
Mail list logo
