For what it's worth, I agree with Russ. Having security as an optional extra [which is how it will look to outsiders] is a bad look for Django, and certainly doesn't fit with the "Secure by default" philosophy.
-- Curtis On 28 August 2014 10:34, Russell Keith-Magee <[email protected]> wrote: > Hi Tim, > > On Thu, Aug 28, 2014 at 3:35 AM, Tim Graham <[email protected]> wrote: > >> I've started tackling one of the ideas that's been on our GSoC ideas >> page for a couple years now: integrating django-secure. I chatted with >> Carl about the idea and he's onboard. There are a couple of design >> decisions we'll need to make. >> > > +1 to the idea. It was part of Chris' original proposal; we just didn't > get around to it with the available time. > > >> 1. How to integrate django-secure with the checks framework >> django-secure essentially implements its own checks framework (which >> predates the one in Django). The tricky part is that django-secure's >> checks are not ones that generally should pass on a >> development instance; they're checks that only make sense to run on a >> production server (or at least against a production settings file). >> I'm thinking to have some way to skip these new checks by default and >> run them only when requested (e.g. manage.py check secure >> --settings=prod_settings). Other options include an entirely separate >> command like django-secure implements (curently called checksecure), >> but perhaps could be called checkdeploy and eventually extended with >> other checks that are relevant only in production. Idea/insight from >> those more familiar with the checks framework (Chris, Russ), would be >> welcome. >> > > Generally, I'd be opposed to the idea of Yet Another Command to run checks > - if you make it optional, it won't get run, and this is something we want > to be forced in front of everyone. > > We use DEBUG as a proxy for "In Production" in other locations in the > codebase - e.g., whether ALLOWED_HOSTS checks are run. If we were to > supplement that with a --production=true/false flag to the checks command > (to override the rare legitimate occasions where DEBUG=True in production, > or DEBUG=False in development), wouldn't that meet all the needs here? > > 2. How to add settings for django-secure >> As discussed in the thread below, I'm going to explore developing an >> API for storing settings on an AppConfig to avoid adding more global >> settings. >> https://groups.google.com/d/topic/django-developers/qnnCLppwA3o/discussion >> >> I have imported django-secure into django.contrib.secure and started >> work on integrating it with the built-in checks framework as well as >> removing some bits of it that have since been added to Django >> (frame-deny, SSL-proxy support). >> > > Is it appropriate for this to be a contrib package? That implies it needs > to be added to INSTALLED_APPS; I'm not convinced that this is a desirable > approach. > > If django-secure is important enough to include as part of Django's > codebase (and I fully agree it is), I'd consider security to be part of > core, not something you can opt out of. Including it as > django.core.checks.security (or similar) would make more sense to me. > > Russ %-) > > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > 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/CAJxq84_Tq1Fnm_pG4pMSy98DOLsnLtVp9jEgTo6X8%2BH%2BJYi1dQ%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CAJxq84_Tq1Fnm_pG4pMSy98DOLsnLtVp9jEgTo6X8%2BH%2BJYi1dQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > 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 [email protected]. To post to this group, send email to [email protected]. 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_XiSCJyiu7Wqwuoe_DjqPJRonFE0-kZvQdQtsGKcbP2CipFg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
