Re: GZipMiddleWare documentation

2013-08-09 Thread Russell Keith-Magee 
On Sat, Aug 10, 2013 at 5:42 AM, Daniele Procida  wrote:

> What should the documents have to say on the subject now, in light of <
> https://www.djangoproject.com/weblog/2013/aug/06/breach-and-django/>?
>
> 
>
> Historically, we haven't updated our documentation to point out bugs, but
in this case, given that there are ongoing security implications, I think
it might be worthwhile to draw attention to this.

I also have a nagging feeling in the back of my head that there have been
questions raised about whether GZIPMiddleware should exist *at all* -- that
there's some niggling detail in the WSGI spec that says that GZip
compression should be applied at the web server level, not the WSGI level.
Can anyone confirm if I'm hallucinating on this point? And if I'm not,
perhaps we should just be deprecating GZipMiddlware?

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Merging Schema Alteration branch

2013-08-09 Thread Russell Keith-Magee 
On Fri, Aug 9, 2013 at 9:36 PM, Andrew Godwin  wrote:

> Hi everyone,
>
> I think it's finally time to look at merging the schema-alteration branch,
> which has gone slightly beyond its name and encompasses the schema
> alteration backends and the migration code as well.
>
> The branch is working, well tested, moderately documented and has all of
> the big changes that happen to other parts of Django outside of the
> migration code (removing syncdb, changing signals, changes to the Field API
> - see the 1.7 release notes in the branch for more).
>
> It's not quite release quality yet - quite a bit of polish remains - but
> it's functional, and I want to merge it now as merging changes back in from
> master is becoming trickier and trickier.
>
> You can see the pull request here:
>
>https://github.com/django/django/pull/376
>
> I'd be aiming to merge this early next week, dependent on feedback.
>

Say… Andrew… there's this guy on a black horse at my front door… says his
name is "Famine"… he wants to talk about the coming apocalypse… :-)

Seriously -- great news, and fantastic work. I'll do what I can to give
this a review some time this week; I'd encourage everyone else to do the
same if they can.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

GZipMiddleWare documentation

2013-08-09 Thread Daniele Procida 
What should the documents have to say on the subject now, in light of 
?



Daniele

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

manage.py and pyc's

2013-08-09 Thread jdetaeye 
The patch in ticket #8280 finds management commands shipped in .pyc, .pyo, 
.zip, .egg files, etc

I find it strange and un-pythonic that the current code uses a walk over the 
file system, rather than the proper python APIs to discover the contents of 
packages...

Johan

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal: Modifying the CSRF protection scheme

2013-08-09 Thread Shai Berger 
On Friday 09 August 2013 18:08:26 Luke Plant wrote:
> On 03/08/13 23:57, Shai Berger wrote:
> > This would work exactly like it works today, except with signed cookies.
> > That is, the "user specific element" is the cookie. CSRF is about
> > tricking the user into submitting a request designed out of the site --
> > an attacker can't just set (or read) cookies on a user's browser, nor
> > read tokens from the page, under the assumptions we're making about the
> > general setup.
> 
> A signed cookie is not "user specific" in the sense I meant. It is only
> user specific if it cannot be transferred to another user and still
> work. But a signed CSRF cookie, with a matching token, can indeed be
> transferred to another user (unless the signed data includes the session
> or user id, for instance).
> 

The token can, but the cookie cannot (without a much more severe attack). This 
is the foundation that Django's current CSRF protection stands on.

> In this case, signing the cookie only adds protection if the SECRET_KEY
> is changed after the exploit. It doesn't stop the attacker getting and
> using a valid CSRF cookie/token in the first place.
> 

I never argued it did more. And as has been noted, no CSRF protection scheme 
can prevent an attacker with an active XSS or MITM exploit from getting CSRF 
cookies and tokens. Such an attacker can completely control the user session.

The point of the change, to repeat and summarize, is:

1) Make it easier to come back from an exploit
and, not discussed in this sub-thread,
2)  add time-limited tokens
3) Make the scheme look more secure at first glance

Note, that is not "make it look more secure than it is" but make it look more 
secure than it looks now".

Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal: Modifying the CSRF protection scheme

2013-08-09 Thread Luke Plant 
On 03/08/13 23:57, Shai Berger wrote:

> This would work exactly like it works today, except with signed cookies. That 
> is, the "user specific element" is the cookie. CSRF is about tricking the 
> user 
> into submitting a request designed out of the site -- an attacker can't just 
> set (or read) cookies on a user's browser, nor read tokens from the page, 
> under the assumptions we're making about the general setup.

A signed cookie is not "user specific" in the sense I meant. It is only
user specific if it cannot be transferred to another user and still
work. But a signed CSRF cookie, with a matching token, can indeed be
transferred to another user (unless the signed data includes the session
or user id, for instance).

In this case, signing the cookie only adds protection if the SECRET_KEY
is changed after the exploit. It doesn't stop the attacker getting and
using a valid CSRF cookie/token in the first place.


Luke

-- 
"DO NOT DISTURB.  I'm disturbed enough already."

Luke Plant || http://lukeplant.me.uk/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.

Merging Schema Alteration branch

2013-08-09 Thread Andrew Godwin 
Hi everyone,

I think it's finally time to look at merging the schema-alteration branch,
which has gone slightly beyond its name and encompasses the schema
alteration backends and the migration code as well.

The branch is working, well tested, moderately documented and has all of
the big changes that happen to other parts of Django outside of the
migration code (removing syncdb, changing signals, changes to the Field API
- see the 1.7 release notes in the branch for more).

It's not quite release quality yet - quite a bit of polish remains - but
it's functional, and I want to merge it now as merging changes back in from
master is becoming trickier and trickier.

You can see the pull request here:

   https://github.com/django/django/pull/376

I'd be aiming to merge this early next week, dependent on feedback.

Andrew

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.