Re: Django and BREACH (remember that?)

[Florian Apolloner]

Hi,

On Monday, August 4, 2014 3:15:15 AM UTC+2, Adam Brenecki wrote:
>
> So, a while ago, BREACH happened, and Django's CSRF implementation was 
> vulnerable, as was Rails'. The paper that discussed it described a 
> mitigation (and a Rails patch had already been made), so I implemented that 
> same mitigation in a Django patch. Discussion on the Trac ticket has 
> stalled, and I've been told this is the place to go.
>

Technically the only mitigation is to disable GZip. That said, randomizing 
the CSRF token provides an extra layer of security, but doesn't necessarily 
help (eg credit card data could still get leaked, so you'd still have to 
disable gzip).

The patch I've written implements this mitigation, with one difference: 
> instead of using xor, it uses a Vigenère cipher (as suggested by FunkyBob), 
> as xor was creating non-printable characters which caused problems. I think 
> this should be OK as Vigenère is commonly used for one-time pads and does 
> more or less the same thing to characters that xor does to bits.
>

What is wrong with xor+base64? Not that Vigenère cipher is complex, but we 
have a pretty hard stance against implementing "crypto" on our own.

Cheers,
Florian

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/67393a16-220c-4419-af4d-648f2d42d841%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django and BREACH (remember that?)

[Adam Brenecki]

On 4 August 2014 17:47, Florian Apolloner  wrote:

>
> (eg credit card data could still get leaked, so you'd still have to
> disable gzip).
>

This patch is entirely about preventing leakage of the CSRF token
specifically; as I understand it (again, disclaimer) it should do that
pretty effectively, but of course it will do nothing at all to stop leakage
of any other data.


>
> What is wrong with xor+base64? Not that Vigenère cipher is complex, but we
> have a pretty hard stance against implementing "crypto" on our own.
>

Nothing, really; that's probably what I would have used had FunkyBob not
suggested the Vigenère cipher. That's a perfectly reasonable stance, and I
can change the patch to do that if it's preferable.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAPkdtoxNCcXxpd-1bY3ayWG76pAckvU4wPACRJp5H3V04PEBJg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django and BREACH (remember that?)

[Florian Apolloner]

On Monday, August 4, 2014 11:01:14 AM UTC+2, Adam Brenecki wrote:
>
> What is wrong with xor+base64? Not that Vigenère cipher is complex, but we 
>> have a pretty hard stance against implementing "crypto" on our own.
>>
>
> Nothing, really; that's probably what I would have used had FunkyBob not 
> suggested the Vigenère cipher. That's a perfectly reasonable stance, and I 
> can change the patch to do that if it's preferable.
>

Yes, please, let's keep this patch as simple as possible. Also the changes 
around 
https://github.com/django/django/pull/1477/files#diff-a3be722ce2831a8d11438021d44cedf1L51
 
need some explaining -- Why can't we return None there anymore? 

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5385d8b8-fcb8-4997-ade5-b19f69b9ced6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSOC] Weekly update

[Tom Christie]

 1) get_fields should return a list instead of a tuple
>>> Previously, get_fields would return a tuple. The main reason was 
related to memory and immutability. After discussing with Russell, we 
decided this endpoint should actually return a list as it is a more suited 
data structure.
>> Can you clarify the reasons for this choice? If it’s just the purity of 
using the “proper” data type, I’m not sure it beats the practicality of 
returning an immutable iterable and avoiding the cost of a copy or the risk 
of incorrect manipulation.
> This is a design decision, tuple performs better.

I'm confused - does it return a list or a tuple? Your previous answer 
mentioned that it was a list, but you later state "This is a design 
decision, tuple performs better.".

Given that it ought to be immutable, I can't see any reason for it *not* to 
be a tuple.

Great work on all of this!

All the best,

  Tom

On Sunday, 3 August 2014 15:48:04 UTC+1, Daniel Pyrathon wrote:
>
> Hi Aymeric,
>
> Thanks for writing back
>
> On Sunday, August 3, 2014 4:24:27 PM UTC+2, Aymeric Augustin wrote:
>>
>> On 3 août 2014, at 15:11, Daniel Pyrathon  wrote:
>>
>> *1) get_fields should return a list instead of a tuple*
>> Previously, get_fields would return a tuple. The main reason was related 
>> to memory and immutability. After discussing with Russell, we decided this 
>> endpoint should actually return a list as it is a more suited data 
>> structure.
>>
>>
>> Can you clarify the reasons for this choice? If it’s just the purity of 
>> using the “proper” data type, I’m not sure it beats the practicality of 
>> returning an immutable iterable and avoiding the cost of a copy or the risk 
>> of incorrect manipulation.
>>
>
> This is a design decision, tuple performs better. 
>  
>
>>
>> The bugs that would occur if the cached value is altered inadvertently 
>> could be very hard to track down.
>>
>
> Only a couple of days...
>
> https://github.com/PirosB3/django/commit/2411ff58d032c38a3151c1e54198723a86e6a8af
>  
>
>>
>> *2) Move tree cache out of the apps registry*
>> The main optimisation for the new API (described here 
>> https://code.djangoproject.com/wiki/new_meta_api#Mainoptimizationpoints) 
>> is currently storing information on the Apps registry. After discussing 
>> with Russell we agree this shouldn't be the correct place to keep this.
>>
>>
>> +1
>>
>> A solution is to store related fields information separately on each 
>> model (
>> https://github.com/PirosB3/django/pull/5/files#diff-98e98c694c90e830f918eb5279134ab9R275).
>>  
>> This has been done, and all tests pass.
>> Unfortunately, there are performance implications with this approach: we 
>> are storing a new list on each model regardless of if it has related fields 
>> or not. I will be discussing with Russell about performance tomorrow.
>>
>>
>> Is the extra cost incurred only at start up ? How large is it? If it 
>> isn’t too bad and and run time performance is unchanged, it could be 
>> acceptable.
>>
>
> Yes! only at start-up. Once cache warming has finished, everything should 
> be as fast (maybe faster, given that we are accessing properties on the 
> single Options instance).
>  
>
>>
>> *3) Revisiting field types and options*
>> Last week I opened this: 
>> https://groups.google.com/forum/#!topic/django-developers/s2Lp2lTEjAE in 
>> order to discuss with the community possible new field and option names. 
>> This week I have actually revisited the fields and options for get_field/s 
>> and I have come up with the following: (…)
>>
>>
>> The latest iteration looks clear, consistent and straightforward. I like 
>> it.
>>
>
> Thanks! Please feel free to comment with doubts or suggestions.
>  
>
>>
>> -- 
>> Aymeric.
>>
>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/dad7fb6e-9984-41aa-814e-d373c384b475%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSOC] Weekly update

[Collin Anderson]

if we do really need a list, could we gain some performance by caching 
tuples and converting them to lists instead of caching lists?

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/54eb742d-6f0d-4f6f-be54-301f665b5859%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSOC] Weekly update

[Daniel Pyrathon]

Hi All,

This has been resolved by using the ImmutableList datastructure

https://github.com/PirosB3/django/blob/soc2014_meta_refactor_upgrade_flags_get_field_tree/django/db/models/options.py#L629

On Monday, August 4, 2014 2:44:38 PM UTC+2, Collin Anderson wrote:
>
> if we do really need a list, could we gain some performance by caching 
> tuples and converting them to lists instead of caching lists?
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f4795467-24c7-4a61-af78-1a5b1a16299d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django and BREACH (remember that?)

[Michael Mior]

This looks good, although it seems like there should be a config setting as 
I could imagine some use cases where the application expects the token not 
to change in this way. I'm not sure how common this and whether or not such 
a setting should be enabled by default, but I think it should be considered.

--
Michael Mior

On Sunday, August 3, 2014 9:15:15 PM UTC-4, Adam Brenecki wrote:
>
> Hi all,
>
> So, a while ago, BREACH happened, and Django's CSRF implementation was 
> vulnerable, as was Rails'. The paper that discussed it described a 
> mitigation (and a Rails patch had already been made), so I implemented that 
> same mitigation in a Django patch. Discussion on the Trac ticket has 
> stalled, and I've been told this is the place to go.
>
> Disclaimer: although I understand enough about it to write the patch, *I'm 
> not a security person* - the reason I'm posting here is that I'm hoping 
> to get an answer from someone that *is* a security person as to whether 
> I'm on the right track.
>
> To jog your memories (and also in the hope that if I'm misunderstanding 
> the problem, someone will correct me), the short version of BREACH is: an 
> attacker forcing a user to visit a HTTPS page that a) is gzipped, and b) 
> contains *in the response body* a secret (in our case, the CSRF token in 
> the form), as well as user input (e.g. reflected URL parameters), then 
> observing the size of the HTTPS responses. When the user input partially or 
> completely matches the secret, the compressed length is slightly shorter, 
> and the attacker can use this to guess the secret byte-by-byte.
>
> In section 3 of the paper, the authors describe a variety of mitigations. 
> One of them is to, on each request where a secret S should appear, 
> generate a new one-time pad P and instead write P + xor(P, S) in the 
> response. (The paper also describes other mitigations, but this is the most 
> feasible¹.)
>
> My understanding is (and I'll reiterate here I'm not a security person) 
> that this should make S impossible to deduce via BREACH, as it doesn't 
> appear directly anywhere in the response. As P takes on a new value with 
> every request, it simply can't be deduced by any method that involves 
> making many requests; therefore the same thing will happen to xor(P, S). 
> (I think the fact that P changes every request might have been a point of 
> confusion in the Trac discussion; there's a lot of comments there talking 
> about trying to deduce P).
>
> The patch I've written implements this mitigation, with one difference: 
> instead of using xor, it uses a Vigenère cipher (as suggested by FunkyBob), 
> as xor was creating non-printable characters which caused problems. I think 
> this should be OK as Vigenère is commonly used for one-time pads and does 
> more or less the same thing to characters that xor does to bits.
>
> This is pretty much what django-debreach does, except that *it* uses AES 
> instead of xor (i.e. the output is K + AES(K, S).). However, this adds 
> processing load to every request and a dependency on PyCrypto, and as far 
> as I can tell this doesn't actually add any benefit over xor/Vigenère.
>
> So, in summary, I think I'm doing nearly exactly what the paper says, and 
> I think it effectively makes the attack practically impossible, but I'd 
> love to hear from someone who has a better idea than I as to if I'm 
> actually correct on all of this.
>
> Thanks,
> Adam
>
> The Trac ticket: https://code.djangoproject.com/ticket/20869
> My pull request: https://github.com/django/django/pull/1477
> The original paper: 
> http://breachattack.com/resources/BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf
>  
> (the relevant bit is section 3.4 at the bottom of page 10)
> The related Rails pull request: https://github.com/rails/rails/pull/11729
>
> ¹ Section 3.4 describes the mitigation I implemented. Section 3.1 
> describes fuzzing the lengths of each response by appending random lengths 
> of garbage data, then immediately dismisses this method as ineffective; 
> Russell Keith-Magee tells me that a discussion within Django reached the 
> same conclusion about this one. Apart from those two, they're all things 
> like rate limiting and separating secrets from user input, which don't seem 
> to me like things we can enforce on a Django level.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/eaf3df25-b49d-4419-aa48-6b5437f3c1f1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django and BREACH (remember that?)

[Florian Apolloner]

On Monday, August 4, 2014 4:21:43 PM UTC+2, Michael Mior wrote:
>
> This looks good, although it seems like there should be a config setting 
> as I could imagine some use cases where the application expects the token 
> not to change in this way. I'm not sure how common this and whether or not 
> such a setting should be enabled by default, but I think it should be 
> considered.
>

Any example for such an App? Ajax single page apps might come to mind -- 
Docs would also need updates, as currently the CSRF token is saved in a JS 
variable…

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/967e40d5-fd53-4fa0-9560-51f5f6b8d847%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSOC] Weekly update

[Łukasz Rekucki]

On 4 August 2014 16:14, Daniel Pyrathon  wrote:
> Hi All,
>
> This has been resolved by using the ImmutableList datastructure
>
> https://github.com/PirosB3/django/blob/soc2014_meta_refactor_upgrade_flags_get_field_tree/django/db/models/options.py#L629
>

But why? What's the benefit over using a tuple? ImmutableList is not
even a list, because it inherits from tuple.

The only other use of this data structure I could find is in upload
handlers and the rationale is that the field suddenly changes from
mutable to immutable. I don't think your case is the same, as fields
are always immutable.

Also, if fields() is immutable, then so should concrete_fields(), etc.


>
> On Monday, August 4, 2014 2:44:38 PM UTC+2, Collin Anderson wrote:
>>
>> if we do really need a list, could we gain some performance by caching
>> tuples and converting them to lists instead of caching lists?
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/f4795467-24c7-4a61-af78-1a5b1a16299d%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.


-- 
Łukasz Rekucki

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAEZs-E%2BPeTGXnQSuQPqqYiOC1zmNd8ZuweoOWm4rASwi14WFdA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Proposal: Use timestamp or hash to determine name when uploading duplicate filenames

[Areski]

Hi,

I opened a ticket suggesting to add a new setting to determine how
duplicate filename will be named:
https://code.djangoproject.com/ticket/23183

Tim asked me to bring this to the mailinglist to discuss further this
change and eventually decide if this is worth considering or if it's a no
go.

You will notice that this can me achieved by using a CustomStorage but it
might be interesting that we consider changing the default behavior in
future versions. The main gain is to keep obfuscated the existing uploaded
filenames on a server. Right now an incremental method is used and so it
makes easy for someone to know which files have been previously uploaded.

What do you think about this issue?


Yours,
/Areski

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMf7LBg1WQCCtYoXqd_LpGSwFWvHNyZyvdLODZQntAVTB4uvFQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: FR: Setting for CSRF Header (pull-request included)

[Wes Alvaro]

I don't see that as a drawback at all. Third party code should not be 
concerned with the CSRF cookie information. There's a separation of 
concerns that's being violated there. Are you speaking from knowledge of 
3rd party code needing access to this data or hypothetically? If you have 
an example, I'd be interested to see why they are accessing it and why they 
aren't implemented as a CSRF middleware.

On Tuesday, July 8, 2014 10:48:43 AM UTC-7, Tim Graham wrote:
>
> The main problem I see with this approach is that it would no longer be 
> straightforward for 3rd party code to access these settings. You'd need 
> something akin to get_user_model() to retrieve the currently installed CSRF 
> middleware so you could access its settings.
>
> Take a look here for examples of 3rd party code that accesses a CSRF 
> setting.
>
> https://github.com/search?q=settings.CSRF_COOKIE_NAME&ref=cmdform&type=Code
>
> On Monday, December 2, 2013 8:05:51 PM UTC-5, Wes Alvaro wrote:
>>
>> I agree; that's exactly the issue I'm trying to rectify. I'd like the 
>> backend to be constant and just work. We have many applications that run 
>> off of the same Django setup, essentially differing only in their handlers. 
>> That's why I'd like to configure the backend once and my front-ends (not 
>> shared, doesn't even have to be Angular) can be good to go with Angular 
>> without having to configure each of them (as we are right now).
>>
>> Conversation on the PR has changed it from *adding* a setting to *removing 
>> *6 settings.
>>
>> I objectively think that this is the best solution. It declutters the 
>> settings module, moving the settings to where they're actually (and only) 
>> used: the middleware class. This makes it stupid easy to subclass and 
>> change the settings to whatever you need. In my case:
>>
>> middleware.py:
>>
>> class AngularCsrfViewMiddleware(csrf.CsrfViewMiddleware):
>>   HEADER_NAME = 'HTTP_X_XSRF_TOKEN'
>>
>> settings.py:
>>
>> MIDDLEWARE_CLASSES = (
>>   'my.app.middleware.AngularCsrfViewMiddleware',
>> )
>>
>> Do you agree that this looks like a better solution? I have created a new 
>> PR (#1995 ) to use this 
>> method and updated the tests.
>> Obviously, there will need to be a deprecation schedule setup for the 
>> settings that have been moved.
>>
>>
>> Thanks!
>> -Wes
>>
>> On Friday, November 22, 2013 2:25:14 PM UTC-8, Lee Trout wrote:
>>>
>>> Looking at it objectively I'm on the fence. Angular's $http is easily 
>>> configurable at the provider level and I feel like the onus is on any 
>>> front-end tool to be flexible enough to work with different servers. At the 
>>> same time if I needed the same code to talk to Django, Flask, and Node then 
>>> I would expect that I could get all of them on some common ground. Of 
>>> course I would probably just roll my own middleware in that case...
>>>
>>> I hold that opinion because maintaining a handful of projects, for me, 
>>> is easier by having the backend as the constant and just remembering when 
>>> I'm rolling djangular that I need to config a couple settings when I start 
>>> off with Angular. (Another being setting X-Requested-With so 
>>> request.is_ajax works as expected).
>>>
>>>
>>> On Fri, Nov 22, 2013 at 2:28 PM, Wesley Alvaro  
>>> wrote:
>>>
 I've been using AngularJS with Django, but I have to override the 
 default CSRF cookie/header values in AngularJS since only one of the 
 values 
 (the cookie name) can be overridden in Django.

 This is a humble request to add a setting for the CSRF header name so 
 that I can maintain it as my "AngularJS CSRF settings" and I'm sure others 
 would like it too.  Changing the cookie and header to XSRF-TOKEN 
 and X-XSRF-TOKEN respectively means that CSRF in Angular just works. Nice. 
 With AngularJS's popularity on the sharp incline, I see this being quite a 
 useful-to-many feature.

 I acknowledge that adding a setting is not ideal, so I welcome any 
 ideas you may have.
 Pull request here: https://github.com/django/django/pull/1958

 Thanks,
 -Wes

 -- 
 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-develop...@googlegroups.com.
 To post to this group, send email to django-d...@googlegroups.com.
 Visit this group at http://groups.google.com/group/django-developers.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/django-developers/65d2ce93-1d70-4972-b635-e65dcb896c61%40googlegroups.com
 .
 For more options, visit https://groups.google.com/groups/opt_out.

>>>
>>>

-- 
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

Re: FR: Setting for CSRF Header (pull-request included)

[Donald Stufft]

On August 4, 2014 at 3:52:56 PM, Wes Alvaro (he...@wesalvaro.com) wrote:
> I don't see that as a drawback at all. Third party code should not be
> concerned with the CSRF cookie information. There's a separation of
> concerns that's being violated there. Are you speaking from knowledge of
> 3rd party code needing access to this data or hypothetically? If you have
> an example, I'd be interested to see why they are accessing it and why they
> aren't implemented as a CSRF middleware.
>  

Well any thing with hardcoded cookie names in javascript would break
with this setting although i’m inclined to say you shouldn’t change
the setting in that case.

--  
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/etPan.53dfe589.6b8b4567.1280a%40Thor.local.
For more options, visit https://groups.google.com/d/optout.

State of concrete fields

[Daniel Pyrathon]

Hi All,

The current Options implementation has properties for "concrete fields".
Technically speaking, concrete fields are data fields without a column. The 
only concrete field in the codebase is ForeignObject. There are 2 classes 
that inherit from ForeignObject: GenericRelation and ForeignKey, but each 
of them fall into different categories (virtual and data). The only 
instances of a ForeignObject in the codebase are in the unit tests, and 
those occurrences can be replaced with a ForeignKey (not tested).
So, my question is:

- Do we really need concrete fields, if ForeignObject is internal and not 
used in any place other than unit tests?
- Are there third-party packages that inherit from ForeignObject? if yes, 
can anyone point which ones?

Perhaps akaariai and loic84 can help, as I know they have done work in this 
area.

As we are formalising the Options API 
(https://groups.google.com/forum/#!topic/django-developers/XfMUjK59Sls) it 
would be great to reduce complexity even more by removing the entire term 
"concrete fields".

Thanks,
Daniel Pyrathon

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c797b8ea-c7dd-44ea-9b3c-3d6aa5df5ddf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django and BREACH (remember that?)

[Donald Stufft]

On August 3, 2014 at 9:48:53 PM, Adam Brenecki (adambrene...@gmail.com) wrote:
> The patch I've written implements this mitigation, with one difference:
> instead of using xor, it uses a Vigenère cipher (as suggested by FunkyBob),
> as xor was creating non-printable characters which caused problems. I think
> this should be OK as Vigenère is commonly used for one-time pads and does
> more or less the same thing to characters that xor does to bits.
>  
> This is pretty much what django-debreach does, except that *it* uses AES
> instead of xor (i.e. the output is K + AES(K, S).). However, this adds
> processing load to every request and a dependency on PyCrypto, and as far
> as I can tell this doesn't actually add any benefit over xor/Vigenère.
>  
> So, in summary, I think I'm doing nearly exactly what the paper says, and I
> think it effectively makes the attack practically impossible, but I'd love
> to hear from someone who has a better idea than I as to if I'm actually
> correct on all of this.

Thoughts:

-1 on implementing our own Vigenère cipher.

If I understand the patch correctly it doesn't use the pad as a nonce exactly,
it will happily accept the same pad + CSRF token multiple times over and over.
Anything that treats the CSRF token as an opaque sequence of characters (which
is essentially what it is prior to this patch) should be backwards compatible
if my understanding is correct. Further more it looks like the original
unpadded CSRF token is still in the cookie so anything that pulls it's tokens
out of the cookie directly should be completely unaffected. 

Is my understanding correct? If so then the only thing I can imagine this
breaking is something that expected a certain length for the CSRF token and
afaik the length of the token is not within our backwards compatibility
promises.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/etPan.53dfe906.327b23c6.1280a%40Thor.local.
For more options, visit https://groups.google.com/d/optout.

Re: FR: Setting for CSRF Header (pull-request included)

[Wes Alvaro]

Yeah, I would agree with you. You should know what your csrf middleware is
doing when you enable it so you should know what cookie name, etc is being
used for your JS.
On Aug 4, 2014 12:56 PM, "Donald Stufft"  wrote:

>
>
> On August 4, 2014 at 3:52:56 PM, Wes Alvaro (he...@wesalvaro.com) wrote:
> > I don't see that as a drawback at all. Third party code should not be
> > concerned with the CSRF cookie information. There's a separation of
> > concerns that's being violated there. Are you speaking from knowledge of
> > 3rd party code needing access to this data or hypothetically? If you have
> > an example, I'd be interested to see why they are accessing it and why
> they
> > aren't implemented as a CSRF middleware.
> >
>
> Well any thing with hardcoded cookie names in javascript would break
> with this setting although i’m inclined to say you shouldn’t change
> the setting in that case.
>
> --
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372
> DCFA
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABTgSpfQzNafO2%3DwdXZp-Xnuo_mgspYF_M7TWnmMu0L_11AzLg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django and BREACH (remember that?)

[Curtis Maloney]

As mentioned the cipher choice was mine. It was, also as mentioned
On Aug 5, 2014 6:11 AM, "Donald Stufft"  wrote:

> On August 3, 2014 at 9:48:53 PM, Adam Brenecki (adambrene...@gmail.com)
> wrote:
> > The patch I've written implements this mitigation, with one difference:
> > instead of using xor, it uses a Vigenère cipher (as suggested by
> FunkyBob),
> > as xor was creating non-printable characters which caused problems. I
> think
> > this should be OK as Vigenère is commonly used for one-time pads and does
> > more or less the same thing to characters that xor does to bits.
> >
> > This is pretty much what django-debreach does, except that *it* uses AES
> > instead of xor (i.e. the output is K + AES(K, S).). However, this adds
> > processing load to every request and a dependency on PyCrypto, and as far
> > as I can tell this doesn't actually add any benefit over xor/Vigenère.
> >
> > So, in summary, I think I'm doing nearly exactly what the paper says,
> and I
> > think it effectively makes the attack practically impossible, but I'd
> love
> > to hear from someone who has a better idea than I as to if I'm actually
> > correct on all of this.
>
> Thoughts:
>
> -1 on implementing our own Vigenère cipher.
>
> If I understand the patch correctly it doesn't use the pad as a nonce
> exactly,
> it will happily accept the same pad + CSRF token multiple times over and
> over.
> Anything that treats the CSRF token as an opaque sequence of characters
> (which
> is essentially what it is prior to this patch) should be backwards
> compatible
> if my understanding is correct. Further more it looks like the original
> unpadded CSRF token is still in the cookie so anything that pulls it's
> tokens
> out of the cookie directly should be completely unaffected.
>
> Is my understanding correct? If so then the only thing I can imagine this
> breaking is something that expected a certain length for the CSRF token and
> afaik the length of the token is not within our backwards compatibility
> promises.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/etPan.53dfe906.327b23c6.1280a%40Thor.local
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSCBTn88VhZFaVXdxmmSWm_sTvLSYw2aY%3DNeRqjEhUj93Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django and BREACH (remember that?)

[Curtis Maloney]

Stupid phone

The reason for that cipher over xor was to avoid non printable characters.

Any other solution is fine. Xoring the lower 4 bits reduced the entropy too
much in my view.
On Aug 5, 2014 6:11 AM, "Donald Stufft"  wrote:

> On August 3, 2014 at 9:48:53 PM, Adam Brenecki (adambrene...@gmail.com)
> wrote:
> > The patch I've written implements this mitigation, with one difference:
> > instead of using xor, it uses a Vigenère cipher (as suggested by
> FunkyBob),
> > as xor was creating non-printable characters which caused problems. I
> think
> > this should be OK as Vigenère is commonly used for one-time pads and does
> > more or less the same thing to characters that xor does to bits.
> >
> > This is pretty much what django-debreach does, except that *it* uses AES
> > instead of xor (i.e. the output is K + AES(K, S).). However, this adds
> > processing load to every request and a dependency on PyCrypto, and as far
> > as I can tell this doesn't actually add any benefit over xor/Vigenère.
> >
> > So, in summary, I think I'm doing nearly exactly what the paper says,
> and I
> > think it effectively makes the attack practically impossible, but I'd
> love
> > to hear from someone who has a better idea than I as to if I'm actually
> > correct on all of this.
>
> Thoughts:
>
> -1 on implementing our own Vigenère cipher.
>
> If I understand the patch correctly it doesn't use the pad as a nonce
> exactly,
> it will happily accept the same pad + CSRF token multiple times over and
> over.
> Anything that treats the CSRF token as an opaque sequence of characters
> (which
> is essentially what it is prior to this patch) should be backwards
> compatible
> if my understanding is correct. Further more it looks like the original
> unpadded CSRF token is still in the cookie so anything that pulls it's
> tokens
> out of the cookie directly should be completely unaffected.
>
> Is my understanding correct? If so then the only thing I can imagine this
> breaking is something that expected a certain length for the CSRF token and
> afaik the length of the token is not within our backwards compatibility
> promises.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/etPan.53dfe906.327b23c6.1280a%40Thor.local
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAG_XiSDDwnEScQ26DJduiYDTyYjCK5B8R0mBvHOr4HQGMBC7%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: FR: Setting for CSRF Header (pull-request included)

[Tim Graham]

Did you look at the github code search link on my previous email? You may 
substitute the other CSRF setting names and determine if you think people 
are doing legitimate things or not.

On Monday, August 4, 2014 5:13:57 PM UTC-4, Wes Alvaro wrote:
>
> Yeah, I would agree with you. You should know what your csrf middleware is 
> doing when you enable it so you should know what cookie name, etc is being 
> used for your JS.
> On Aug 4, 2014 12:56 PM, "Donald Stufft" > 
> wrote:
>
>>
>>
>> On August 4, 2014 at 3:52:56 PM, Wes Alvaro (he...@wesalvaro.com 
>> ) wrote:
>> > I don't see that as a drawback at all. Third party code should not be
>> > concerned with the CSRF cookie information. There's a separation of
>> > concerns that's being violated there. Are you speaking from knowledge of
>> > 3rd party code needing access to this data or hypothetically? If you 
>> have
>> > an example, I'd be interested to see why they are accessing it and why 
>> they
>> > aren't implemented as a CSRF middleware.
>> >
>>
>> Well any thing with hardcoded cookie names in javascript would break
>> with this setting although i’m inclined to say you shouldn’t change
>> the setting in that case.
>>
>> --
>> Donald Stufft
>> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 
>> DCFA
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4c5ccb64-3164-4f5d-a119-6249e7d493f5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal: Use timestamp or hash to determine name when uploading duplicate filenames

[Collin Anderson]

It seems to me a setting is not the way to go, but a custom storage would 
be better. I've made a custom storage the computes the md5 of the content 
and uses that as the directory of the file, though that generate a whole 
lot of directories. In a lot of ways, I think it would be great if django 
could try to check to see if the duplicate files also have the same content 
and re-use the first file if so. Otherwise I'm still in the mindset that 
filename_1, filename_2 is an improvement over filename_, filename__, 
filename___. :).

It would be nice if upload_to functions had access to the file content.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/79f70121-9449-4b72-b89b-f3842950b399%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.