Re: GitHub migration planning

2012-04-18 Thread Dalton Barreto
Em 18 de abril de 2012 21:13, Luke Granger-Brown  escreveu:
>
> On Wed, Apr 18, 2012 at 11:55 PM, Dalton Barreto 
> wrote:
>>
>> Em 18 de abril de 2012 19:46, Dalton Barreto 
>> escreveu:
>> > Em 18 de abril de 2012 18:44, philipn  escreveu:
>>
>> Hmm, this would probably disable pull requests too. Not a good idea,
>> assuming that
>> contributions  will be accepted as pull requests on this new repo.
>
>
> Fortunately it doesn't. Pull requests can be run independently of issues, if
> issues have been disabled.
>

This is awesome! Thanks Luke and Karen!


-- 
Dalton Barreto
http://daltonmatos.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: GitHub migration planning

2012-04-18 Thread Donald Stufft
Github issues do not have the ability for anyone to close, tag, or create
milestones. You have to be the creator of the ticket or someone with
commit access. Django's track instance allows anyone to participate
in this way and is one of the major reasons to my knowledge that
Django will keep it's trace instance.


On Wednesday, April 18, 2012 at 7:39 PM, Łukasz Rekucki wrote:

> On 19 April 2012 00:55, Donald Stufft  (mailto:donald.stu...@gmail.com)> wrote:
> > Github Issues are not flexible enough for Django.
>  
>  
> That's rather a vague statement. Github issues are actually more
> *flexible* then Trac as you can define any set of tags for an issue.
> What Django could possibly want to have is a way to create extra
> constraints on the tags, but as a matter of fact, the current Trac
> instance doesn't do that! (you can have an issue with "tests needed"
> but without "patch needs improvement").
>  
> --  
> Łukasz Rekucki
>  
> --  
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com 
> (mailto:django-developers@googlegroups.com).
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com 
> (mailto:django-developers+unsubscr...@googlegroups.com).
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
>  
>  


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: GitHub migration planning

2012-04-18 Thread Luke Granger-Brown
On Wed, Apr 18, 2012 at 11:55 PM, Dalton Barreto wrote:

> Em 18 de abril de 2012 19:46, Dalton Barreto 
> escreveu:
> > Em 18 de abril de 2012 18:44, philipn  escreveu:
>
> Hmm, this would probably disable pull requests too. Not a good idea,
> assuming that
> contributions  will be accepted as pull requests on this new repo.
>

Fortunately it doesn't. Pull requests can be run independently of issues,
if issues have been disabled.

Luke GB

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: GitHub migration planning

2012-04-18 Thread Karen Tracey
On Wed, Apr 18, 2012 at 6:55 PM, Dalton Barreto  wrote:
>> Maybe the best way to avoid that people create issues on github is to
>> disable it for the
>> official repository. This is possible through the Github's Admin interface.
>>
>
> Hmm, this would probably disable pull requests too

No, it does not, unless I am mis-understanding what you are saying.

https://github.com/django/django/

has no issues (issues is unchecked in admin area), but it has pull requests.

Karen

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: GitHub migration planning

2012-04-18 Thread Łukasz Rekucki
On 19 April 2012 00:55, Donald Stufft  wrote:
> Github Issues are not flexible enough for Django.
>

That's rather a vague statement. Github issues are actually more
*flexible* then Trac as you can define any set of tags for an issue.
What Django could possibly want to have is a way to create extra
constraints on the tags, but as a matter of fact, the current Trac
instance doesn't do that!  (you can have an issue with "tests needed"
but without "patch needs improvement").

-- 
Łukasz Rekucki

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: GitHub migration planning

2012-04-18 Thread Dalton Barreto
Em 18 de abril de 2012 19:46, Dalton Barreto  escreveu:
> Em 18 de abril de 2012 18:44, philipn  escreveu:
>> Hey folks!
>>
>> I started a wiki page to help plan a migration to GitHub:
>>
>> https://code.djangoproject.com/wiki/GitHub%20Migration
>>
>> I don't know what I'm doing, but I do know that the current Trac setup
>> (attaching patches, etc) is less accessible to non-core contributors than
>> GitHub and I'd love to do anything I can to help make this better.
>>
>
> Maybe the best way to avoid that people create issues on github is to
> disable it for the
> official repository. This is possible through the Github's Admin interface.
>

Hmm, this would probably disable pull requests too. Not a good idea,
assuming that
contributions  will be accepted as pull requests on this new repo.


-- 
Dalton Barreto
http://daltonmatos.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: GitHub migration planning

2012-04-18 Thread Donald Stufft
Github Issues are not flexible enough for Django. 


On Wednesday, April 18, 2012 at 6:53 PM, Alex Ogier wrote:

> On Wed, Apr 18, 2012 at 6:46 PM, Dalton Barreto  (mailto:daltonma...@gmail.com)> wrote:
> > Em 18 de abril de 2012 18:44, philipn  > (mailto:phil...@gmail.com)> escreveu:
> > > Hey folks!
> > > 
> > > I started a wiki page to help plan a migration to GitHub:
> > > 
> > > https://code.djangoproject.com/wiki/GitHub%20Migration
> > > 
> > > I don't know what I'm doing, but I do know that the current Trac setup
> > > (attaching patches, etc) is less accessible to non-core contributors than
> > > GitHub and I'd love to do anything I can to help make this better.
> > > 
> > 
> > 
> > Maybe the best way to avoid that people create issues on github is to
> > disable it for the
> > official repository. This is possible through the Github's Admin interface.
> > 
> 
> 
> Err, I think the point was that Trac is less accessible than Github so
> Django *should* be using Github Issues instead.
> 
> Best,
> Alex Ogier
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com 
> (mailto:django-developers@googlegroups.com).
> To unsubscribe from this group, send email to 
> django-developers+unsubscr...@googlegroups.com 
> (mailto:django-developers+unsubscr...@googlegroups.com).
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
> 
> 


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: GitHub migration planning

2012-04-18 Thread Alex Ogier
On Wed, Apr 18, 2012 at 6:46 PM, Dalton Barreto  wrote:
> Em 18 de abril de 2012 18:44, philipn  escreveu:
>> Hey folks!
>>
>> I started a wiki page to help plan a migration to GitHub:
>>
>> https://code.djangoproject.com/wiki/GitHub%20Migration
>>
>> I don't know what I'm doing, but I do know that the current Trac setup
>> (attaching patches, etc) is less accessible to non-core contributors than
>> GitHub and I'd love to do anything I can to help make this better.
>>
>
> Maybe the best way to avoid that people create issues on github is to
> disable it for the
> official repository. This is possible through the Github's Admin interface.
>

Err, I think the point was that Trac is less accessible than Github so
Django *should* be using Github Issues instead.

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: GSoC 2012: Security Enhancements

2012-04-18 Thread Luke Plant
On 18/04/12 20:05, Paul McMillan wrote:

> My suggestion here is to include optional support for the Origin
> header as follows:
> - if present and null, fail the CSRF check
> - if present and not null, use in alongside the Referer header
> - if absent, keep current behavior
> 
> As a general rule, if a browser sends an origin header, that value is
> more reliable (harder for malicious sites to manipulate, less often
> stripped by firewalls, less often disabled by users) than the referer
> header. This addition won't improve CSRF protection for older
> browsers, but it also won't break anything for them. For users with
> newer browsers, it should prevent CSRF even in cases when the CSRF
> token is stolen due to misconfiguration or user error.

That does sound like a useful additional behaviour.

One query: are you sure it is harder to manipulate? In particular, I
remember from a while back that Flash allowed some headers to be
manipulated, which caused problems, and they fixed it by blacklisting
some headers, I think including referer. Did they also fix Origin?

The vulnerability I'm thinking about is this one I think:

http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2011-February/007533.html

Luke


-- 
"My capacity for happiness you could fit into a matchbox without
taking out the matches first." (Marvin the paranoid android)

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: GitHub migration planning

2012-04-18 Thread Dalton Barreto
Em 18 de abril de 2012 18:44, philipn  escreveu:
> Hey folks!
>
> I started a wiki page to help plan a migration to GitHub:
>
> https://code.djangoproject.com/wiki/GitHub%20Migration
>
> I don't know what I'm doing, but I do know that the current Trac setup
> (attaching patches, etc) is less accessible to non-core contributors than
> GitHub and I'd love to do anything I can to help make this better.
>

Maybe the best way to avoid that people create issues on github is to
disable it for the
official repository. This is possible through the Github's Admin interface.

Thanks,

-- 
Dalton Barreto
http://daltonmatos.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



GitHub migration planning

2012-04-18 Thread philipn
Hey folks!

I started a wiki page to help plan a migration to GitHub:

https://code.djangoproject.com/wiki/GitHub%20Migration

I don't know what I'm doing, but I do know that the current Trac setup 
(attaching patches, etc) is less accessible to non-core contributors than 
GitHub and I'd love to do anything I can to help make this better.

-Philip

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/WT9jb7Zh2d4J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Proposal: Stop supporting MySQL < 5.0 in Django 1.5

2012-04-18 Thread Ramiro Morales
Hi all,

I've opened ticket [1]#18116 to track this cleanup change.

This change would allow to close a handful of tickets about half-backed
compatibility with deprecated MySQL 4.x.

More specifically the commit would make Django trunk require MySQL
5.0.3 or newer. This will allow avoid a limitation on the length
(<= 255) of char fields imposed by older MySQL versions.

Opinions on the proposal and the respective patch are welcome.

-- 
Ramiro Morales

1. https://code.djangoproject.com/ticket/18116#comment:7

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: GSoC 2012: Security Enhancements

2012-04-18 Thread Paul McMillan
There seems to be  some confusion about CORS (a hairy draft spec that
is not fully implemented in any browser, and not appropriate for
inclusion in Django at this time) and the "Origin" header (aka Web
Origin, rfc6454).

http://tools.ietf.org/html/rfc6454
https://wiki.mozilla.org/Security/Origin
http://www.w3.org/TR/access-control/#origin-request-header

The Origin header defined in rfc6454 is compatible with the CORS
origin header, but does not require full CORS support from the browser
or the server to be useful.

In my tests with Firefox and Chrome, both sent the origin header
properly when making potentially state-changing cross-origin requests
(both AJAX and standard form POST requests).

My suggestion here is to include optional support for the Origin
header as follows:
- if present and null, fail the CSRF check
- if present and not null, use in alongside the Referer header
- if absent, keep current behavior

As a general rule, if a browser sends an origin header, that value is
more reliable (harder for malicious sites to manipulate, less often
stripped by firewalls, less often disabled by users) than the referer
header. This addition won't improve CSRF protection for older
browsers, but it also won't break anything for them. For users with
newer browsers, it should prevent CSRF even in cases when the CSRF
token is stolen due to misconfiguration or user error.

-Paul

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: GSoC 2012: Security Enhancements

2012-04-18 Thread Luke Plant
Sorry to reply twice, a comment on a different part:

On 15/04/12 05:23, Rohan Jain wrote:
> On 22:50 +0100 / 13 Apr, Luke Plant wrote:
>> .. At the moment, it seems that few browsers send the
>> 'Origin' header for normal HTML requests. (Recent versions of Chrome,
>> Firefox and Opera do not, I don't know about IE).
> 
> Page, http://caniuse.com/cors mentions the browsers and their versions
> which support CORS. A big share of browser does support it and another
> big one (constituting old IE and Opera) does not. We cannot expect
> these browsers to go away anytime soon, so we have to keep maintaining
> a compatibility system.
> 
> Since http referrer is already being used in case of secure requests,
> how about something similar in normal requests? Isn't the argument
> about referrer being absent only in 0.2% case or less valid here? Is
> 0.2% too significant for normal requests?

The page you linked to shows browsers that support CORS, which is quite
different from browsers that send Origin with normal HTTP requests (i.e.
non XMLHttpRequests requests) - in my own tests I can't find any browser
that sends it for normal HTML requests.

This means that it might be useful as an alternative way of addressing
the problem with AJAX, but even there I think it is of dubious value: if
we deploy a method that means that AJAX works automatically (without,
for example, the jQuery fix we include in our docs) on the basis of the
Origin header, everything will work fine in development, where most
people don't test IE regularly, and will fail for Internet Explorer in
production, which is not very nice. It is better to fail early.

Regards,

Luke

-- 
"My capacity for happiness you could fit into a matchbox without
taking out the matches first." (Marvin the paranoid android)

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.



Re: GSoC 2012: Security Enhancements

2012-04-18 Thread Luke Plant
On 15/04/12 05:23, Rohan Jain wrote:
> On 22:50 +0100 / 13 Apr, Luke Plant wrote:
>> The reason for the strict referer checking under HTTPS is set out here:
>>
>> https://code.djangoproject.com/wiki/CsrfProtection
>>
>> Particularly, it is to fix the 'CSRF + MITM' attack that is possible
>> under HTTPS. The key elements are set out in the following scenario
>> (although it is not the only variation):
>>
>>  - a client connects to a site via HTTP: http://example.com/
>>  - in the response, an active MITM attacker sets a cookie over
>>HTTP for example.com
>>  - this cookie will be used by the client when it connects over HTTPS
>>to the same domain (this is the fundamental problem, but we can't
>>fix it - it's what browsers do).
>>  - the MITM also inserts a POST form in the HTTP response.
>>The form has a CSRF token that matches the cookie that was
>>set by the attacker.
>>The forms targets https://example.com/ and is automatically
>>submitted by javascript.
>>
>> Without strict referer checking, the POST request will succeed, even
>> though it is forged.
>>
>> Signing the cookie or token value does no good at all, because the
>> attacker can retrieve a valid cookie/token pair directly from
>> https://example.com/.
> 
> I am a bit confused about this. How can an attacker extract the token
> out of the signed cookie without the private key? There is a
> possibility that the attacker deletes and sets the cookie right out,
> but since that case won't be correctly signed server can handle it
> securely.

They don't need to extract the token, they just need to replay an
existing good token/cookie pair, which they can get directly from the
server any time they want.

(Also, signing does nothing to hide the token. Are you actually talking
about encryption here? But even if you encrypt it, it doesn't help - the
only thing that matters is that the CSRF form token 'matches' the CSRF
cookie, whatever your definition of 'match', and that can be achieved by
getting the pair from the server.)

Luke

-- 
"My capacity for happiness you could fit into a matchbox without
taking out the matches first." (Marvin the paranoid android)

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.