Hi Roy, There's also a more recent thread on this: https://groups.google.com/u/2/g/django-developers/c/CIPgeTetYpk
Tom On Sun, 26 Jul 2020 at 18:00, Roy Smith <r...@panix.com> wrote: > In the past, I've worked on a couple of django projects where we violated > the: > > # SECURITY WARNING: keep the secret key used in production secret!" > > > advice because on day one, somebody didn't know what we they were doing > and never fixed it. Looking around at a collection of django projects (by > various developers), I see that's often the case. SECRET_KEY, oauth keys, > aws keys, etc all end up in settings.py files. And show up in github, etc. > > This is not terribly surprising. I expect most people just sit down with the > tutorial > <https://docs.djangoproject.com/en/3.0/intro/tutorial01/#creating-a-project>, > follow the first example: > > $ django-admin startproject mysite > > > and instantly have a working, but insecure, setup. > > So, why not have startproject start people off on the right foot? Build a > settings.py file and a secret_settings.py file. Put the SECRET_KEY in > secrets.py. Have settings.py do "from secret_settings import SECRET_KEY". > Make secret_settings.py mode 0400 by default (or whatever that translates > to on windows). Print out a message telling people to exclude > secret_settings.py from version control. > > > As people add more secrets, they have a low-effort path to continuing to > do something reasonable. A more sophisticated user can tear that out and > replace it with their own secrets infrastructure. But, at least we will > have started newbies off with something reasonable. > > I see this has been discussed before > <https://groups.google.com/forum/#!searchin/django-developers/startproject%7Csort:date/django-developers/TtCyuDp4Exk/kk12ic7YCQAJ>, > but I disagree with a lot of the opinions in that thread. This wouldn't be > forcing developers to do it any specific way. It just provides a default > that's better than the current default. Expecting that newbies to follow > best practices just because they're documented somewhere is irrational, as > can be seen by perusing github. > > -- > 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/E7AED784-145B-45A5-9C23-8700E72E5CB8%40panix.com > <https://groups.google.com/d/msgid/django-developers/E7AED784-145B-45A5-9C23-8700E72E5CB8%40panix.com?utm_medium=email&utm_source=footer> > . > -- 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/CAHoz%3DMaEHnGimaV6zcvuTU9fTytbr1D4ixJOVLzFJnBtzpFpfw%40mail.gmail.com.
