Re: Google Patch Rewards program

[William Vincent]

This is great! To the extent we have this teed up internally, makes it much 
easier for DSF to go to Google and coordinate. And even if Google doesn't 
pan out, having structure makes it easier for us to, for example, find 
funding if some fundraising projects in the works pan out.

On Tuesday, December 31, 2019 at 11:40:15 AM UTC-5, Dan Davis wrote:
>
> Another good security improvement would be to allow the database password 
> and other database information to support AWS Secrets Manager, Goolge 
> Secrets Management, and HashiCorp vault (+ others).
> I have done this in a private package used at the National Library of 
> Medicine, but my package is both private and limited to RDS PostgreSQL and 
> AWS Secrets Manager.
>
> On Tue, Dec 31, 2019 at 11:25 AM Dan Davis  > wrote:
>
>> Taymon Beal writes:
>> > First-class integration with one or more secrets management systems, 
>> both to generally contain secrets better and more specifically 
>> > so people aren't so tempted to check SECRET_KEYs and database passwords 
>> into source control. (I think this was mentioned in the list of GSoC 
>> project ideas.)
>>
>> What secrets management systems are you thinking about?   I wrote 
>> confsecrets, whose Django integration never worked right, assuming that I'd 
>> port it to support the following:
>> * HashiCorp vault
>> * AWS Secrets Manager
>> * Google Secrets Management
>>
>> I also need to switch it from cryptdome to cryptography or make it 
>> agnostic on these.
>>
>> P.S. - I have some very limited applied cryptography knowledge - couple 
>> chapters of Bruce Schneier and some hands-on learning, such as securing 
>> single license features with signatures based on my employer's license 
>> signing private key, and discovering that a customer literally pulled one 
>> set of feature.xml/feature.sig files from one tarball, and another from 
>> another tarball to game my home-grown licensing system.  I helped that 
>> company eventually move to a Secure USB dongle, and that was my last moment 
>> of systems software development :)
>>
>> On Sat, Dec 28, 2019 at 11:23 PM Taymon A. Beal > > wrote:
>>
>>> (Disclosure: I'm on Google's security team, and my views on this topic 
>>> are informed by what kinds of things we tend to look for in Web frameworks, 
>>> but here I don't speak for them, only for myself.)
>>>
>>> Beyond those already mentioned, here are some potential security 
>>> improvements I'd like to see in Django:
>>>
>>>- Support for contextual autoescaping in the template system. The 
>>>current autoescaping behavior is better than nothing, but it still makes 
>>>XSS far too easy, since different kinds of strings are XSS sinks in 
>>>different contexts. 
>>>
>>> https://github.com/google/closure-templates/blob/master/documentation/concepts/auto-escaping.md
>>>  shows 
>>>an example of how to do this sort of thing more securely.
>>>- First-class integration with one or more secrets management 
>>>systems, both to generally contain secrets better and more specifically 
>>> so 
>>>people aren't so tempted to check SECRET_KEYs and database passwords 
>>> into 
>>>source control. (I think this was mentioned in the list of GSoC project 
>>>ideas.)
>>>- Capability-based authorization. Right now, you have to explicitly 
>>>check for all relevant permissions everywhere, and if you forget, or 
>>> even 
>>>if you accidentally include the wrong variable in a template, you can 
>>> leak 
>>>data or worse. It'd be much safer if the allowed permissions could be 
>>>defined at a single choke point, and from there, all model access within 
>>> a 
>>>request could be mediated by the specified authorization rules. Ideally 
>>>data that the current user isn't supposed to see would not even be 
>>> fetched 
>>>from the database.
>>>
>>> Taymon
>>>
>>> On Sat, Dec 21, 2019 at 11:29 PM Asif Saif Uddin >> > wrote:
>>>
 Really good plans Adam!

 On Saturday, December 21, 2019 at 11:51:11 PM UTC+6, Adam Johnson wrote:
>
> I just saw Google is expanding their Patch Rewards program for open 
> source security improvements: 
> https://security.googleblog.com/2019/12/announcing-updates-to-our-patch-rewards.html
>
> They are offering two tiers of rewards - $5,000 or $30,000 - for  open 
> source projects making security improvements. I think Django would find 
> it 
> hard to fit in the "small" tier - we generally fix known vulnerabilities 
> quickly - but we could use the "large" tier to fund a bigger GSoC style 
> project. I suspect it would need active involvement from a DSF member to 
> push it through. Not sure how the funding would work in terms of DSF and 
> paying for development time on the project.
>
> Some projects that could fit:
>
>- 2FA built-in to django.contrib.auth (as suggested for GSoC as 
>well in this thread: 
>
> 

Re: Google Patch Rewards program

[Dan Davis]

Another good security improvement would be to allow the database password
and other database information to support AWS Secrets Manager, Goolge
Secrets Management, and HashiCorp vault (+ others).
I have done this in a private package used at the National Library of
Medicine, but my package is both private and limited to RDS PostgreSQL and
AWS Secrets Manager.

On Tue, Dec 31, 2019 at 11:25 AM Dan Davis  wrote:

> Taymon Beal writes:
> > First-class integration with one or more secrets management systems,
> both to generally contain secrets better and more specifically
> > so people aren't so tempted to check SECRET_KEYs and database passwords
> into source control. (I think this was mentioned in the list of GSoC
> project ideas.)
>
> What secrets management systems are you thinking about?   I wrote
> confsecrets, whose Django integration never worked right, assuming that I'd
> port it to support the following:
> * HashiCorp vault
> * AWS Secrets Manager
> * Google Secrets Management
>
> I also need to switch it from cryptdome to cryptography or make it
> agnostic on these.
>
> P.S. - I have some very limited applied cryptography knowledge - couple
> chapters of Bruce Schneier and some hands-on learning, such as securing
> single license features with signatures based on my employer's license
> signing private key, and discovering that a customer literally pulled one
> set of feature.xml/feature.sig files from one tarball, and another from
> another tarball to game my home-grown licensing system.  I helped that
> company eventually move to a Secure USB dongle, and that was my last moment
> of systems software development :)
>
> On Sat, Dec 28, 2019 at 11:23 PM Taymon A. Beal 
> wrote:
>
>> (Disclosure: I'm on Google's security team, and my views on this topic
>> are informed by what kinds of things we tend to look for in Web frameworks,
>> but here I don't speak for them, only for myself.)
>>
>> Beyond those already mentioned, here are some potential security
>> improvements I'd like to see in Django:
>>
>>- Support for contextual autoescaping in the template system. The
>>current autoescaping behavior is better than nothing, but it still makes
>>XSS far too easy, since different kinds of strings are XSS sinks in
>>different contexts.
>>
>> https://github.com/google/closure-templates/blob/master/documentation/concepts/auto-escaping.md
>>  shows
>>an example of how to do this sort of thing more securely.
>>- First-class integration with one or more secrets management
>>systems, both to generally contain secrets better and more specifically so
>>people aren't so tempted to check SECRET_KEYs and database passwords into
>>source control. (I think this was mentioned in the list of GSoC project
>>ideas.)
>>- Capability-based authorization. Right now, you have to explicitly
>>check for all relevant permissions everywhere, and if you forget, or even
>>if you accidentally include the wrong variable in a template, you can leak
>>data or worse. It'd be much safer if the allowed permissions could be
>>defined at a single choke point, and from there, all model access within a
>>request could be mediated by the specified authorization rules. Ideally
>>data that the current user isn't supposed to see would not even be fetched
>>from the database.
>>
>> Taymon
>>
>> On Sat, Dec 21, 2019 at 11:29 PM Asif Saif Uddin 
>> wrote:
>>
>>> Really good plans Adam!
>>>
>>> On Saturday, December 21, 2019 at 11:51:11 PM UTC+6, Adam Johnson wrote:

 I just saw Google is expanding their Patch Rewards program for open
 source security improvements:
 https://security.googleblog.com/2019/12/announcing-updates-to-our-patch-rewards.html

 They are offering two tiers of rewards - $5,000 or $30,000 - for  open
 source projects making security improvements. I think Django would find it
 hard to fit in the "small" tier - we generally fix known vulnerabilities
 quickly - but we could use the "large" tier to fund a bigger GSoC style
 project. I suspect it would need active involvement from a DSF member to
 push it through. Not sure how the funding would work in terms of DSF and
 paying for development time on the project.

 Some projects that could fit:

- 2FA built-in to django.contrib.auth (as suggested for GSoC as
well in this thread:

 https://groups.google.com/forum/#!msg/django-developers/ifYT6lX8nmg/1nVO3As1AwAJ
)
- Adding CSP to SecurityMiddleware and shipping some default
(django-csp is a good start but requires users to actively seek it:
https://django-csp.readthedocs.io/en/latest/ )
- Adding CORS to Django itself (I'm maintaining
django-cors-headers, but its design is a bit pants
https://github.com/adamchainz/django-cors-headers )
- Other things in James Bennett's list of suggestions from this
thread in 

Re: Google Patch Rewards program

[Dan Davis]

Taymon Beal writes:
> First-class integration with one or more secrets management systems, both
to generally contain secrets better and more specifically
> so people aren't so tempted to check SECRET_KEYs and database passwords
into source control. (I think this was mentioned in the list of GSoC
project ideas.)

What secrets management systems are you thinking about?   I wrote
confsecrets, whose Django integration never worked right, assuming that I'd
port it to support the following:
* HashiCorp vault
* AWS Secrets Manager
* Google Secrets Management

I also need to switch it from cryptdome to cryptography or make it agnostic
on these.

P.S. - I have some very limited applied cryptography knowledge - couple
chapters of Bruce Schneier and some hands-on learning, such as securing
single license features with signatures based on my employer's license
signing private key, and discovering that a customer literally pulled one
set of feature.xml/feature.sig files from one tarball, and another from
another tarball to game my home-grown licensing system.  I helped that
company eventually move to a Secure USB dongle, and that was my last moment
of systems software development :)

On Sat, Dec 28, 2019 at 11:23 PM Taymon A. Beal 
wrote:

> (Disclosure: I'm on Google's security team, and my views on this topic are
> informed by what kinds of things we tend to look for in Web frameworks, but
> here I don't speak for them, only for myself.)
>
> Beyond those already mentioned, here are some potential security
> improvements I'd like to see in Django:
>
>- Support for contextual autoescaping in the template system. The
>current autoescaping behavior is better than nothing, but it still makes
>XSS far too easy, since different kinds of strings are XSS sinks in
>different contexts.
>
> https://github.com/google/closure-templates/blob/master/documentation/concepts/auto-escaping.md
>  shows
>an example of how to do this sort of thing more securely.
>- First-class integration with one or more secrets management systems,
>both to generally contain secrets better and more specifically so people
>aren't so tempted to check SECRET_KEYs and database passwords into source
>control. (I think this was mentioned in the list of GSoC project ideas.)
>- Capability-based authorization. Right now, you have to explicitly
>check for all relevant permissions everywhere, and if you forget, or even
>if you accidentally include the wrong variable in a template, you can leak
>data or worse. It'd be much safer if the allowed permissions could be
>defined at a single choke point, and from there, all model access within a
>request could be mediated by the specified authorization rules. Ideally
>data that the current user isn't supposed to see would not even be fetched
>from the database.
>
> Taymon
>
> On Sat, Dec 21, 2019 at 11:29 PM Asif Saif Uddin  wrote:
>
>> Really good plans Adam!
>>
>> On Saturday, December 21, 2019 at 11:51:11 PM UTC+6, Adam Johnson wrote:
>>>
>>> I just saw Google is expanding their Patch Rewards program for open
>>> source security improvements:
>>> https://security.googleblog.com/2019/12/announcing-updates-to-our-patch-rewards.html
>>>
>>> They are offering two tiers of rewards - $5,000 or $30,000 - for  open
>>> source projects making security improvements. I think Django would find it
>>> hard to fit in the "small" tier - we generally fix known vulnerabilities
>>> quickly - but we could use the "large" tier to fund a bigger GSoC style
>>> project. I suspect it would need active involvement from a DSF member to
>>> push it through. Not sure how the funding would work in terms of DSF and
>>> paying for development time on the project.
>>>
>>> Some projects that could fit:
>>>
>>>- 2FA built-in to django.contrib.auth (as suggested for GSoC as well
>>>in this thread:
>>>
>>> https://groups.google.com/forum/#!msg/django-developers/ifYT6lX8nmg/1nVO3As1AwAJ
>>>)
>>>- Adding CSP to SecurityMiddleware and shipping some default
>>>(django-csp is a good start but requires users to actively seek it:
>>>https://django-csp.readthedocs.io/en/latest/ )
>>>- Adding CORS to Django itself (I'm maintaining django-cors-headers,
>>>but its design is a bit pants
>>>https://github.com/adamchainz/django-cors-headers )
>>>- Other things in James Bennett's list of suggestions from this
>>>thread in May 2018:
>>>
>>> https://groups.google.com/forum/#!msg/django-developers/DDpkrvFdnvk/J46ZbakxAgAJ
>>>
>>> Thoughts?
>>> --
>>> Adam
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> 

Re: Google Patch Rewards program

[Robert Roskam]

I've made some minor contributions to django-csp, and CSP is an active area 
of interest to me. Should I send out the proposal myself or work with the 
core team?

On Saturday, December 21, 2019 at 12:51:11 PM UTC-5, Adam Johnson wrote:
>
> I just saw Google is expanding their Patch Rewards program for open source 
> security improvements: 
> https://security.googleblog.com/2019/12/announcing-updates-to-our-patch-rewards.html
>
> They are offering two tiers of rewards - $5,000 or $30,000 - for  open 
> source projects making security improvements. I think Django would find it 
> hard to fit in the "small" tier - we generally fix known vulnerabilities 
> quickly - but we could use the "large" tier to fund a bigger GSoC style 
> project. I suspect it would need active involvement from a DSF member to 
> push it through. Not sure how the funding would work in terms of DSF and 
> paying for development time on the project.
>
> Some projects that could fit:
>
>- 2FA built-in to django.contrib.auth (as suggested for GSoC as well 
>in this thread: 
>
> https://groups.google.com/forum/#!msg/django-developers/ifYT6lX8nmg/1nVO3As1AwAJ
>  
>)
>- Adding CSP to SecurityMiddleware and shipping some default 
>(django-csp is a good start but requires users to actively seek it: 
>https://django-csp.readthedocs.io/en/latest/ )
>- Adding CORS to Django itself (I'm maintaining django-cors-headers, 
>but its design is a bit pants 
>https://github.com/adamchainz/django-cors-headers )
>- Other things in James Bennett's list of suggestions from this thread 
>in May 2018: 
>
> https://groups.google.com/forum/#!msg/django-developers/DDpkrvFdnvk/J46ZbakxAgAJ
>
> Thoughts?
> -- 
> Adam
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/af22d246-59b7-4c07-9197-74a0a3b4a1d7%40googlegroups.com.

Re: Google Patch Rewards program

[Guido Vranken]

Here's an idea, but you'll have to ask around if it's eligible for a
patch reward.

Some time ago I wrote fuzzers for Django, which have been running 24/7
on OSS-Fuzz since.
Thanks to this fuzzer, a few DoS bugs were found [2] and it would
likely have caught some historic DoS bugs.

The current fuzzer tests a host of utility functions [3]. If a
time-out, out-of-memory or uncaught exception occurs, the security
team will receive a notification from OSS-Fuzz containing instructions
on how to reproduce the bug, and the bug can be fixed.

Writing additional fuzzers consists of:

- Implement a function 'FuzzerRunOne(FuzzerInput)'
- Do something with FuzzerInput, which is a bytes() object and
consists of pseudo-random data generated by the fuzzing engine
- Raise an (uncaught) exception if something is amiss, eg. a html
escape function that returns valid html tags (try parsing the output
with BeautifulSoup for example) from a crafted input

Some basic constraints: the fuzzer must be:

1. Not very slow
2. Deterministic
3. Preferably not use file/network IO/forking other processes (this
could affect 1 and 2)

If you are keen, I can help you get things set up (and to be clear, I
don't need a cut of the reward for that. Just happy to see my fuzzers
put to good use). You won't need to touch C/C++ or other code;
implementing dynamic tests in Python is sufficient.

[1] https://github.com/google/oss-fuzz
[2] https://www.djangoproject.com/weblog/2019/aug/01/security-releases/
[3] https://github.com/guidovranken/django-fuzzers/blob/master/utils.py

On Sun, Dec 29, 2019 at 5:23 AM Taymon A. Beal  wrote:
>
> (Disclosure: I'm on Google's security team, and my views on this topic are 
> informed by what kinds of things we tend to look for in Web frameworks, but 
> here I don't speak for them, only for myself.)
>
> Beyond those already mentioned, here are some potential security improvements 
> I'd like to see in Django:
>
> Support for contextual autoescaping in the template system. The current 
> autoescaping behavior is better than nothing, but it still makes XSS far too 
> easy, since different kinds of strings are XSS sinks in different contexts. 
> https://github.com/google/closure-templates/blob/master/documentation/concepts/auto-escaping.md
>  shows an example of how to do this sort of thing more securely.
> First-class integration with one or more secrets management systems, both to 
> generally contain secrets better and more specifically so people aren't so 
> tempted to check SECRET_KEYs and database passwords into source control. (I 
> think this was mentioned in the list of GSoC project ideas.)
> Capability-based authorization. Right now, you have to explicitly check for 
> all relevant permissions everywhere, and if you forget, or even if you 
> accidentally include the wrong variable in a template, you can leak data or 
> worse. It'd be much safer if the allowed permissions could be defined at a 
> single choke point, and from there, all model access within a request could 
> be mediated by the specified authorization rules. Ideally data that the 
> current user isn't supposed to see would not even be fetched from the 
> database.
>
> Taymon
>
> On Sat, Dec 21, 2019 at 11:29 PM Asif Saif Uddin  wrote:
>>
>> Really good plans Adam!
>>
>> On Saturday, December 21, 2019 at 11:51:11 PM UTC+6, Adam Johnson wrote:
>>>
>>> I just saw Google is expanding their Patch Rewards program for open source 
>>> security improvements: 
>>> https://security.googleblog.com/2019/12/announcing-updates-to-our-patch-rewards.html
>>>
>>> They are offering two tiers of rewards - $5,000 or $30,000 - for  open 
>>> source projects making security improvements. I think Django would find it 
>>> hard to fit in the "small" tier - we generally fix known vulnerabilities 
>>> quickly - but we could use the "large" tier to fund a bigger GSoC style 
>>> project. I suspect it would need active involvement from a DSF member to 
>>> push it through. Not sure how the funding would work in terms of DSF and 
>>> paying for development time on the project.
>>>
>>> Some projects that could fit:
>>>
>>> 2FA built-in to django.contrib.auth (as suggested for GSoC as well in this 
>>> thread: 
>>> https://groups.google.com/forum/#!msg/django-developers/ifYT6lX8nmg/1nVO3As1AwAJ
>>>  )
>>> Adding CSP to SecurityMiddleware and shipping some default (django-csp is a 
>>> good start but requires users to actively seek it: 
>>> https://django-csp.readthedocs.io/en/latest/ )
>>> Adding CORS to Django itself (I'm maintaining django-cors-headers, but its 
>>> design is a bit pants https://github.com/adamchainz/django-cors-headers )
>>> Other things in James Bennett's list of suggestions from this thread in May 
>>> 2018: 
>>> https://groups.google.com/forum/#!msg/django-developers/DDpkrvFdnvk/J46ZbakxAgAJ
>>>
>>> Thoughts?
>>> --
>>> Adam
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to 

Re: Google Patch Rewards program

[Taymon A. Beal]

(Disclosure: I'm on Google's security team, and my views on this topic are
informed by what kinds of things we tend to look for in Web frameworks, but
here I don't speak for them, only for myself.)

Beyond those already mentioned, here are some potential security
improvements I'd like to see in Django:

   - Support for contextual autoescaping in the template system. The
   current autoescaping behavior is better than nothing, but it still makes
   XSS far too easy, since different kinds of strings are XSS sinks in
   different contexts.
   
https://github.com/google/closure-templates/blob/master/documentation/concepts/auto-escaping.md
shows
   an example of how to do this sort of thing more securely.
   - First-class integration with one or more secrets management systems,
   both to generally contain secrets better and more specifically so people
   aren't so tempted to check SECRET_KEYs and database passwords into source
   control. (I think this was mentioned in the list of GSoC project ideas.)
   - Capability-based authorization. Right now, you have to explicitly
   check for all relevant permissions everywhere, and if you forget, or even
   if you accidentally include the wrong variable in a template, you can leak
   data or worse. It'd be much safer if the allowed permissions could be
   defined at a single choke point, and from there, all model access within a
   request could be mediated by the specified authorization rules. Ideally
   data that the current user isn't supposed to see would not even be fetched
   from the database.

Taymon

On Sat, Dec 21, 2019 at 11:29 PM Asif Saif Uddin  wrote:

> Really good plans Adam!
>
> On Saturday, December 21, 2019 at 11:51:11 PM UTC+6, Adam Johnson wrote:
>>
>> I just saw Google is expanding their Patch Rewards program for open
>> source security improvements:
>> https://security.googleblog.com/2019/12/announcing-updates-to-our-patch-rewards.html
>>
>> They are offering two tiers of rewards - $5,000 or $30,000 - for  open
>> source projects making security improvements. I think Django would find it
>> hard to fit in the "small" tier - we generally fix known vulnerabilities
>> quickly - but we could use the "large" tier to fund a bigger GSoC style
>> project. I suspect it would need active involvement from a DSF member to
>> push it through. Not sure how the funding would work in terms of DSF and
>> paying for development time on the project.
>>
>> Some projects that could fit:
>>
>>- 2FA built-in to django.contrib.auth (as suggested for GSoC as well
>>in this thread:
>>
>> https://groups.google.com/forum/#!msg/django-developers/ifYT6lX8nmg/1nVO3As1AwAJ
>>)
>>- Adding CSP to SecurityMiddleware and shipping some default
>>(django-csp is a good start but requires users to actively seek it:
>>https://django-csp.readthedocs.io/en/latest/ )
>>- Adding CORS to Django itself (I'm maintaining django-cors-headers,
>>but its design is a bit pants
>>https://github.com/adamchainz/django-cors-headers )
>>- Other things in James Bennett's list of suggestions from this
>>thread in May 2018:
>>
>> https://groups.google.com/forum/#!msg/django-developers/DDpkrvFdnvk/J46ZbakxAgAJ
>>
>> Thoughts?
>> --
>> Adam
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/3c2cb15c-3c55-431c-8ee7-a5a207051389%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHRQ%3D87016c3XEJSje1i%2BHZBfag%2BiyGVQXr5OX7xKr3QH2i_nA%40mail.gmail.com.

Re: Google Patch Rewards program

[Asif Saif Uddin]

Really good plans Adam!

On Saturday, December 21, 2019 at 11:51:11 PM UTC+6, Adam Johnson wrote:
>
> I just saw Google is expanding their Patch Rewards program for open source 
> security improvements: 
> https://security.googleblog.com/2019/12/announcing-updates-to-our-patch-rewards.html
>
> They are offering two tiers of rewards - $5,000 or $30,000 - for  open 
> source projects making security improvements. I think Django would find it 
> hard to fit in the "small" tier - we generally fix known vulnerabilities 
> quickly - but we could use the "large" tier to fund a bigger GSoC style 
> project. I suspect it would need active involvement from a DSF member to 
> push it through. Not sure how the funding would work in terms of DSF and 
> paying for development time on the project.
>
> Some projects that could fit:
>
>- 2FA built-in to django.contrib.auth (as suggested for GSoC as well 
>in this thread: 
>
> https://groups.google.com/forum/#!msg/django-developers/ifYT6lX8nmg/1nVO3As1AwAJ
>  
>)
>- Adding CSP to SecurityMiddleware and shipping some default 
>(django-csp is a good start but requires users to actively seek it: 
>https://django-csp.readthedocs.io/en/latest/ )
>- Adding CORS to Django itself (I'm maintaining django-cors-headers, 
>but its design is a bit pants 
>https://github.com/adamchainz/django-cors-headers )
>- Other things in James Bennett's list of suggestions from this thread 
>in May 2018: 
>
> https://groups.google.com/forum/#!msg/django-developers/DDpkrvFdnvk/J46ZbakxAgAJ
>
> Thoughts?
> -- 
> Adam
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3c2cb15c-3c55-431c-8ee7-a5a207051389%40googlegroups.com.

Re: Google Patch Rewards program

[Matemática A3K]

On Sat, Dec 21, 2019 at 12:51 PM Adam Johnson  wrote:

> I just saw Google is expanding their Patch Rewards program for open source
> security improvements:
> https://security.googleblog.com/2019/12/announcing-updates-to-our-patch-rewards.html
>
> They are offering two tiers of rewards - $5,000 or $30,000 - for  open
> source projects making security improvements. I think Django would find it
> hard to fit in the "small" tier - we generally fix known vulnerabilities
> quickly - but we could use the "large" tier to fund a bigger GSoC style
> project. I suspect it would need active involvement from a DSF member to
> push it through. Not sure how the funding would work in terms of DSF and
> paying for development time on the project.
>
> Some projects that could fit:
>
>- 2FA built-in to django.contrib.auth (as suggested for GSoC as well
>in this thread:
>
> https://groups.google.com/forum/#!msg/django-developers/ifYT6lX8nmg/1nVO3As1AwAJ
>)
>- Adding CSP to SecurityMiddleware and shipping some default
>(django-csp is a good start but requires users to actively seek it:
>https://django-csp.readthedocs.io/en/latest/ )
>- Adding CORS to Django itself (I'm maintaining django-cors-headers,
>but its design is a bit pants
>https://github.com/adamchainz/django-cors-headers )
>- Other things in James Bennett's list of suggestions from this thread
>in May 2018:
>
> https://groups.google.com/forum/#!msg/django-developers/DDpkrvFdnvk/J46ZbakxAgAJ
>
> Thoughts?
>

Sounds great, CSP (being the base for or including subresource integrity)
and improved system security checks seems to fit very well the "a
significant new security feature" category (thinking in 2FA for GSoC)


> --
> Adam
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMyDDM0MV-XLf8VV7ux%3DgY6J3pDhGAGrosG9gATNyRXZoRcZfw%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CA%2BFDnhKLozkUJ3r9pjuuJcvbB8%2B4LmsLafYQmROwoZeXFvoF0w%40mail.gmail.com.