Re: RFC: Query Methods

[Michael Mior]

Got interested in this after a referral from the tricket tracker. Couldn't 
this specific case be solved with a simple change to __getattr__ on 
QuerySet?

 def __getattr__(self, attr):
 try:
 qmethod = getattr(self.manager, attr).im_func
 is_querymethod = qmethod.is_querymethod
 except AttributeError, exc:
 raise AttributeError(attr)

 if is_querymethod:
-return curry(qmethod, self)
+return curry(qmethod, self.manager)
 raise AttributeError(attr)

The only issue I see here is that it assumes self.manager is always defined 
so this would break if a QuerySet was instantiated outside of 
Manager.get_query_set(). But really, it doesn't make sense to add the 
@querymethod decorator on QuerySet functions anyway.

- Michael

Le jeudi 12 janvier 2012 09:05:57 UTC-5, Anssi Kääriäinen a écrit :
>
> On Jan 12, 2:24 pm, Zachary Voase  wrote: 
> > I strongly feel that switching around managers like that would be an 
> > example of overengineering. 
>
> I tend to over-engineer things. It is easy to add the manager 
> switching later on if needed. And it is easy to switch managers by 
> just changing qs.manager if really needed. So, I agree on leaving that 
> feature out. 
>
> > Here's the change I propose:
> https://github.com/zacharyvoase/django/compare/master...feature-query... 
> > 
> > It's very light for now, I'm not sure if there are other corner cases 
> > where it breaks, but it's the simplest thing that could possibly work, 
> > and it's conceptually very easy to understand. 
>
> And in the implementation I disagree. The implementation magically 
> changes what self references in querymethods. This will break any code 
> that wants to reference self in manager. For example: 
>
> def get_id_list_by_raw_sql(self, some_params): 
> return cursor.execute("select if from sometable where someparam = 
> %s", (some_param,)) 
>
> @querymethod 
> def list_interesting_subjects(self, some_params): 
> self.filter(id__in=self.get_id_list_by_raw_sql(some_params)) 
>
> Now, the above will work just fine if called through manager, but it 
> will not work if called through queryset, because self suddenly refers 
> to the qs, not to the manager. Depending how it is called. So, I would 
> suggest an approach like in my version, where self is always the 
> manager, and you get the queryset by self.get_query_set() (or maybe 
> with self.base_qs, which is a property returning either 
> self.get_query_set() or the queryset called from). 
>
> The main reason why I think it is a bad idea to "transfer" the method 
> to the qs is that if you do that, you will confuse people (what does 
> self refer to?), forbid some usecases, and gain exactly nothing by 
> doing that. And that can not be changed later on. Why not just let the 
> method be always bound to the manager instance? That is much cleaner. 
> This all assuming I actually understand what the patch does. Can't 
> test it currently... 
>
> Am I missing something that is gained by currying the method to 
> queryset instead of letting it be bound to the manager? 
>
> Still another idea is to somehow patch the parameters to the method in 
> querymethod, so that the queryset to chain to would be passed as a 
> parameter to the querymethod. It would either be self.get_query_set() 
> or the queryset called through. 
>
>  - Anssi


Le jeudi 12 janvier 2012 09:05:57 UTC-5, Anssi Kääriäinen a écrit :
>
> On Jan 12, 2:24 pm, Zachary Voase  wrote: 
> > I strongly feel that switching around managers like that would be an 
> > example of overengineering. 
>
> I tend to over-engineer things. It is easy to add the manager 
> switching later on if needed. And it is easy to switch managers by 
> just changing qs.manager if really needed. So, I agree on leaving that 
> feature out. 
>
> > Here's the change I propose:
> https://github.com/zacharyvoase/django/compare/master...feature-query... 
> > 
> > It's very light for now, I'm not sure if there are other corner cases 
> > where it breaks, but it's the simplest thing that could possibly work, 
> > and it's conceptually very easy to understand. 
>
> And in the implementation I disagree. The implementation magically 
> changes what self references in querymethods. This will break any code 
> that wants to reference self in manager. For example: 
>
> def get_id_list_by_raw_sql(self, some_params): 
> return cursor.execute("select if from sometable where someparam = 
> %s", (some_param,)) 
>
> @querymethod 
> def list_interesting_subjects(self, some_params): 
> self.filter(id__in=self.get_id_list_by_raw_sql(some_params)) 
>
> Now, the above will work just fine if called through manager, but it 
> will not work if called through queryset, because self suddenly refers 
> to the qs, not to the manager. Depending how it is called. So, I would 
> suggest an approach like in my version, where self is always the 
> manager, and you get the queryset by self.get_query_set() (or maybe 
> with s

Re: Django git guidelines

[Michael Mior]

Hi all,

New to this list but I saw this post and thought I would chime in with my 
two cents. I'm not really a Django contributor (yet) but I have a fair bit 
of experience using Git and Django both personally and professionally.

I can understand the hesitation for using rebase on public commits. I think 
rebasing after a pull request has already been issued might not be the best 
idea. However, I think contributors should generally be encouraged to 
rebase rather than pull. The reason being is that if a topic branch is 
closely tracking it's parent (which I assume would be a common situation) 
you end up with a lot of merge commits which make the history hard to 
follow.

If a change in a commit requires adapting due to upstream changes, I 
personally think it's preferable for the contributor to do the work of 
hiding this fact via rebase. It helps group logical changes together and 
simply makes the history much easier to read. For development branches, I 
don't see the fact that history is changing  to be a problem. (If someone 
is basing work off a development branch, should they not expect things to 
break?)

Anyway, really happy to see Django move to GitHub and looking forward to 
tossing some code your way in the future. :)

Cheers, 
-- Michael

Le vendredi 18 mai 2012 04:43:13 UTC-4, Anssi Kääriäinen a écrit :
>
> A heads up: I am working on Git and Github usage guidelines. There is 
> a ticket https://code.djangoproject.com/ticket/18307, and I have a 
> github branch with some initial work 
> https://github.com/akaariai/django/tree/django_git_guidelines 
> (or for changeset 
> https://github.com/akaariai/django/compare/django_git_guidelines) 
>
> The guidelines in short: 
>  - For trivial patches use pull requests directly 
>  - For non-trivial patches, create a trac ticket, announce your work 
> by linking to your github branch, and when your work is ready to be 
> pulled in, only then do a pull request 
>  - Aim for logically contained commits, commit messages of 50 char 
> summary line, 72 char paragraphs thereafter. 
>  - When upstream has changed use git rebase instead of git pull 
>  - When you do additional fixes to your work, use git rebase -i so 
> that your work still fullfills the logical commits requirement. 
>
> Lots of more details in the WIP branch. All feedback welcomed. Lets 
> keep the discussion of any high-level issues here on django- 
> developers, as the choices made impact the whole community. 
>
> The biggest issue is how we aim to use the pull requests. My take on 
> this is that pull requests should be only used for work ready for 
> committer. That is, the original author feels the work is ready, or he 
> doesn't know how to do anything more. If the pull requests are used 
> for feature requests or work-in-progress patches we risk having lots 
> of open tickets and lots of open pull requests. 
>
> I have tried to gather pieces of wisdom around the net. I am not too 
> experienced with Git, so if you have experience with the above 
> mentioned and/or other Git workflows feedback is appreciated. 
>
> - Anssi


Le vendredi 18 mai 2012 04:43:13 UTC-4, Anssi Kääriäinen a écrit :
>
> A heads up: I am working on Git and Github usage guidelines. There is 
> a ticket https://code.djangoproject.com/ticket/18307, and I have a 
> github branch with some initial work 
> https://github.com/akaariai/django/tree/django_git_guidelines 
> (or for changeset 
> https://github.com/akaariai/django/compare/django_git_guidelines) 
>
> The guidelines in short: 
>  - For trivial patches use pull requests directly 
>  - For non-trivial patches, create a trac ticket, announce your work 
> by linking to your github branch, and when your work is ready to be 
> pulled in, only then do a pull request 
>  - Aim for logically contained commits, commit messages of 50 char 
> summary line, 72 char paragraphs thereafter. 
>  - When upstream has changed use git rebase instead of git pull 
>  - When you do additional fixes to your work, use git rebase -i so 
> that your work still fullfills the logical commits requirement. 
>
> Lots of more details in the WIP branch. All feedback welcomed. Lets 
> keep the discussion of any high-level issues here on django- 
> developers, as the choices made impact the whole community. 
>
> The biggest issue is how we aim to use the pull requests. My take on 
> this is that pull requests should be only used for work ready for 
> committer. That is, the original author feels the work is ready, or he 
> doesn't know how to do anything more. If the pull requests are used 
> for feature requests or work-in-progress patches we risk having lots 
> of open tickets and lots of open pull requests. 
>
> I have tried to gather pieces of wisdom around the net. I am not too 
> experienced with Git, so if you have experience with the above 
> mentioned and/or other Git workflows feedback is appreciated. 
>
> - Anssi

-- 
You received this message because you are subscribed to the Google 

Django 1.5.2

[Michael Mior]

Just wondering if there's an ETA on Django 1.5.2. Currently there's one 
blocking issue in 1.5.1 that's preventing me from upgrading from 1.4 (
https://code.djangoproject.com/ticket/20257). If there's some outstanding 
things that need to be cleaned up, I'm happy to pitch in. Thanks!

Cheers,
--
Michael Mior
michael.m...@gmail.com

-- 
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: Django 1.5.2

[Michael Mior]

Thanks Jacob! Greatly appreciated :)

Le mardi 9 juillet 2013 19:04:26 UTC-4, Jacob Kaplan-Moss a écrit :
>
> Hey Michael -
>
> We don't have a schedule for 1.5.2 at the moment, but I'll take a look and 
> see if I can get a release out sometime soon. No promises, but I'll do my 
> best.
>
> Jacob
>
>
> On Tue, Jul 9, 2013 at 11:00 AM, Michael Mior 
> 
> > wrote:
>
>> Just wondering if there's an ETA on Django 1.5.2. Currently there's one 
>> blocking issue in 1.5.1 that's preventing me from upgrading from 1.4 (
>> https://code.djangoproject.com/ticket/20257). If there's some 
>> outstanding things that need to be cleaned up, I'm happy to pitch in. 
>> Thanks!
>>
>> Cheers,
>> --
>> Michael Mior
>> michae...@gmail.com 
>>
>> -- 
>> 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.
>> 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 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

[Michael Mior]

In light of BREACH[1] it might be worth looking into having the option of 
adding a one-time pad to the CSRF token as well. Has anyone started 
development on any of the suggestions in this thread yet? If not, it's 
something I'd be interested in exploring.

Cheers,
--
Michael Mior
michael.m...@gmail.com

[1] 
http://breachattack.com/resources/BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf

Le mardi 30 juillet 2013 13:29:39 UTC-4, Paul McMillan a écrit :
>
> I agree with Jacob on both points. 
>
> +1 from me, especially since neither of these changes should require 
> changes in application code which is already using the interface 
> correctly. 
>
> -Paul 
>
> On Tue, Jul 30, 2013 at 1:22 PM, Jacob Kaplan-Moss 
> > 
> wrote: 
> > Hey Shai - 
> > 
> > I have no objections to this change. I think it's got a slight whiff of 
> > security theatre, in that it *looks* like it adds more protection than 
> it 
> > *actually* does. However, I, too, have spent a ton of time talking 
> auditors 
> > down from "OMG Django is vulnerable to CSRF!" and I'd like to do less of 
> > that. I like that rotating SECRET_KEY invalidates CSRF tokens. 
> > 
> > Time-limiting is a nice feature too, actually. Again the perceived 
> security 
> > is higher than the actual added security, but the general principle of 
> > giving people more control is a good one. I'm sure there's some audit 
> > checklist out there that has "CSRF tokens must not be valid for longer 
> than 
> > X hours" or something on it, and helping our users tick those boxes 
> isn't 
> > such a bad thing. 
> > 
> > So yeah, lukewarm praise from me at best, but since there's at least a 
> bit 
> > of real improvement here I see no reason this shouldn't go in. +1 from 
> me. 
> > 
> > Jacob 
> > 
> > 
> > On Sat, Jul 27, 2013 at 6:12 PM, Shai Berger 
> > > 
> wrote: 
> >> 
> >> Hi everybody, 
> >> 
> >> TL;DR: A simple change can make Django's CSRF protection a little 
> better; 
> >> an 
> >> additional, slightly less simple one, can also make it look better. 
> >> 
> >> Django's CSRF protection scheme is a bit unusual; unlike most such 
> >> schemes, it 
> >> does not rely on a value stored in the server that needs to be matched 
> by 
> >> a 
> >> submitted token and is replaced with every submission, but rather on a 
> >> constant value stored in a cookie. This generally works (for details of 
> >> how 
> >> and under what conditions exactly, see [1]), but has two minor 
> problems: 
> >> 
> >> 1) It is unusual, and in particular diverges from what OWASP[2] 
> >> recommends[3]; 
> >> as a result, security analysts often think it is not secure. They have 
> >> been 
> >> proven wrong in all cases members of core are aware of, but proving it 
> >> again 
> >> and again is a nuisance, and there may be bad PR related to this. 
> >> 
> >> 2) It carries a "second-order" vulnerability: If your site has been 
> >> compromised (XSS, Man-in-the-middle, or server compromise) then you 
> become 
> >> persistently vulnerable to CSRF. All of these vulnerabilities are way 
> >> worse 
> >> than CSRF and render all CSRF protection schemes worthless while they 
> >> last; 
> >> the point is *not* that they allow CSRF, but rather that they allow 
> CSRF 
> >> to be 
> >> performed after the main hole has been plugged. This is because the 
> >> attacker 
> >> can use the main vulnerability to "steal", or even set, csrftoken 
> cookie 
> >> values, which they can then use later. After a successful attack of 
> this 
> >> magnitude, you need to reset the csrftoken cookies of all users, and 
> this 
> >> is 
> >> neither obvious nor straightforward to do. 
> >> 
> >> Django's unique scheme does have two advantages over the more common 
> >> solutions, which we would like to keep: 
> >> 
> >> 1) It is not tied to sessions, users, or site-stored per-user data, 
> >> allowing 
> >> CSRF protection to a wider range of users 
> >> 
> >> 2) It avoids the problem of having only one "current" token, which 
> causes 
> >> the 
> >> submission of one form to invalidate forms open in other browser tabs. 
> >> 
> >> To improve on both problem issues, while keeping the advantages, I 
> sug

Re: Add strutctured settings module to django 1.7?

[Michael Mior]

Given that, what about incorporating something like DJ-Database-URL[1] into 
Django? It would be great if this could be the default if DATABASES was 
left unspecified.

[1] https://github.com/kennethreitz/dj-database-url

Le mercredi 25 septembre 2013 19:45:20 UTC-4, Russell Keith-Magee a écrit :
>
>
> On Thu, Sep 26, 2013 at 4:21 AM, VernonCole 
> > wrote:
>
>> I find myself using up lots of time and keystrokes explaining about the 
>> benefits and methods of a structured settings module in django.  
>> For example: 
>> Using-a-Structured-Settings-environment
>>
>> It occurs to me that life would be easier if django shipped already set 
>> up for structured settings, rather than having to retro-fit it.  The pull 
>> request I sent to formhub could be a starting point for the conversion. (
>> formhub/pull/1240)   The 
>> changes to core are simple enough that I could do it.
>>
>> Your  opinions please, Would such a change be good for django 1.7?
>>
>
> Based on conversations that I had at the sprints at DjangoCon US, I'd say 
> probably not -- because the winds are blowing in another direction.
>
> The primary reason to need structured settings like this is because your 
> development environment is different to your deployment environment (e.g., 
> different passwords, paths and so on). 
>
> However, the emerging best practice for this sort of thing is best 
> described by the "12 factor" approach:
>
> http://12factor.net
>
> Factors 10 and 3 are the most relevant to this discussion -- 10 says that 
> development and production should be the same; 3 says that anything that 
> needs to vary should be set as an environment variable, and consumed from 
> there.
>
> So - I'd expect to see Django moving towards better support for a 12 
> factor environment, rather than embedding separate settings files as a 
> deployment practice.
>
> 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: [ANNOUNCE] Django 1.6 release candidate available

[Michael Mior]

Looks like an awesome release coming up! Big thanks to the Django team :) 
Looking forward to trying it out.

One comment about the fact that set_password() now (correctly) makes blank 
passwords valid. I could imagine some users have assumed that 
set_password('') was the same as set_unusable_password(). It might be worth 
noting more prominently in the release notes since if this is the case, 
there are obvious security implications.

--
Michael Mior
michael.m...@gmail.com

Le mardi 22 octobre 2013 23:08:33 UTC-4, James Bennett a écrit :
>
> It's almost here!
>
> Tonight we've issued a release candidate for Django 1.6. Information, 
> including links to downloads and release notes, is available on the Django 
> project blog:
>
> https://www.djangoproject.com/weblog/2013/oct/22/16c1/
>

-- 
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/0c2b88c8-4789-44b3-9157-2763c6bcb671%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal to add a secure JSON encoding template tag

[Michael Mior]

I've used django-jsonify (https://pypi.python.org/pypi/django-jsonify/) in 
the the past for this successfully. I'm not certain of the security of the 
code since unfortunately I didn't have the time to do a proper audit, but 
it seemed to handle some common cases.

--
Michael Mior

On Tuesday, May 13, 2014 6:03:43 AM UTC-4, David Evans wrote:
>
> There was some discussion previously (see 
> https://code.djangoproject.com/ticket/17419) of adding a JSON encoding 
> filter to Django. This was rejected as being impossible (or very difficult) 
> to do securely. However the requirement to embed JSON in an HTML page is 
> quite a common one, and it's easy to get wrong and create XSS 
> vulnerabilities. We should make it easy for people to do the right thing.
>
> I propose a ``json`` tag (implementation 
> here<https://gist.github.com/evansd/41ea9dfc90d87f6afde1>) 
> which outputs the entire script element as well as the JSON data. By 
> enforcing the context in which in the JSON is output, it's possible to 
> escape it securely.
>
> It would have two basic modes of operation. The first, and recommended, 
> one would look like this:
>
> {% json data id="initial-data" %}
>
>
> and would produce HTML like this:
>
> 
>   {"foo": "bar"}
> 
>
>
> The resulting data would be accessed in JavaScript like this:
>
> var el = document.getElementById('initial-data');
> var initialData = JSON.parse(el.textContent || el.innerText);
>
>
> This is compatible with a strict Content Security Policy which prohibits 
> all in-page script execution and maintains a clean separation between 
> passive data and executable code.
>
> The second mode of operation would look like this:
>
> {% json data var="initialData" %}
>
>
> and would produce HTML like this:
>
>
> 
>   var initialData = {"foo": "bar"};
> 
>
>
> This isn't compatible with strict CSP but it is perhaps simpler and more 
> familiar to many developers, and not fundamentally insecure, so it should 
> still be supported.
>
> Of course, the key issue is whether this can be done securely. In the gist 
> below is a proposed implementation with links to the sources I've used to 
> ensure I'm escaping things correctly: 
> https://gist.github.com/evansd/41ea9dfc90d87f6afde1
>
> If people are happy with it then I can create a proper pull request with 
> docs etc.
>
> Thanks,
>
> Dave
>

-- 
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/b47c4e41-a476-450b-a854-5f87f277224f%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.