Earlier today a message posted to the django-developers mailing list
publicly disclosed what was later determined to be an exploitable security
issue in Django.
As such, we have short-circuited our normal one-week process and moved to
immediately issuing new releases to remedy the problem.
Full d
On Sunday, September 15, 2013 3:13:09 AM UTC+3, Curtis Maloney wrote:
>
> Hey, thanks for that!
>
> It would be nice to have something that would chart this over time...
> something like some people have set up for GCC.
>
> I've never been able to get djangobench to give meaningful results,
> oth
Hey, thanks for that!
It would be nice to have something that would chart this over time...
something like some people have set up for GCC.
I've never been able to get djangobench to give meaningful results,
otherwise I'd do it.
Mmm... perhaps I've just found a use for my odroid :)
--
Curtis
>
> 4. More important changes in code:
>>
>> - Introduced RAW_SETTINGS_MODULE [1]. I use it in compatibility checks to
>>> test
>>
>> if `TEST_RUNNER` setting was overriden [2].
>>
>>
>
> Have a look at the internals of the diffsettings management command -- I'm
>> not sure RAW_SETTINGS_MODU
I just ran djangobench comparing 1.5 to 1.6. The biggest thing seems to be
form_create bechmark, the average is 15x slower. But for some reason the
minimum runtime is just 1.16x slower. This seems a bit strange. This might
be worth more investigation.
Otherwise there doens't seem to be anything
Currently there is no restriction on the length of passwords accepted by
the login form. Assuming someone is using an appropriately expensive
hashing function for passwords, this means an attacker can chew through a
_lot_ of CPU pretty easily, just by sending huge junk passwords.
Setting an upp
