The number of default-generated SECRET_KEYs that can be found publicly on GitHub alone suggests to me that no, the existence of that page is not sufficient to protect users from making this mistake.
Deploying to production already requires worrying about things more complicated than a SECRET_KEY, like having a database that actually durably persists your data (yes, SQLite does this in some deployment environments, but in many popular ones it doesn't). And if your Django site is accessible to the public internet, and its SECRET_KEY is compromised, then so is the site itself. So I'm not convinced that making it easier for users to quickly get a vulnerable site up and running on the public internet is in their interest. Local development is, of course, a different story. Have we considered letting Django run with a blank SECRET_KEY in local scenarios? I guess DEBUG = True might be an okay way to handle that, though I can't help but wonder if there's a better alternative for making doing the safe thing the path of least resistance. We certainly don't want to push users to enable DEBUG in production... Taymon On Sat, Nov 16, 2019 at 7:14 AM Adam Johnson <m...@adamj.eu> wrote: > There is such a link since 2013: > https://github.com/django/django/commit/912b5d2a6bc78067d6a7e130f10514c51bd1a58f > > On Thu, 24 Oct 2019 at 23:31, Olivier Dalang <olivier.dal...@gmail.com> > wrote: > >> Hi, >> >> Just a reminder about this page in the docs: >> https://docs.djangoproject.com/en/2.2/howto/deployment/checklist/ >> It basically already covers it all. Maybe a direct link to that page from >> the settings file would be good enough? >> >> Cheers, >> >> Olivier >> >> On Thu, Oct 24, 2019, 04:45 Josh Smeaton <josh.smea...@gmail.com> wrote: >> >>> A quick idea from the top of my head, is to change the assignment of >>> SECRET_KEY in the generated settings to something like: >>> >>> SECRET_KEY = os.environ.get("DJANGO_SECRET_KEY", >>> "insecure-<generatedvalue>") >>> >>> It signals that secrets in the environment are a good idea, that the >>> default generated value is insecure, and it still has a random part so that >>> default sites aren't automatically hackable when deployed. There's no >>> impact to people just getting started. >>> >>> We could go a small step forward and use `check --deploy` to check for >>> the substring `insecure` (even though I believe the KEY is technically >>> bytes?). >>> >>> Just throwing something out there. >>> >>> >>> On Monday, 21 October 2019 23:48:59 UTC+11, Taymon A. Beal wrote: >>>> >>>> Is the requirement here to avoid introduce additional barriers to >>>> getting up and running in local development, or to deploying a site so that >>>> it's accessible from the public internet? >>>> >>>> Both of these are important goals, but trading off security against the >>>> latter worries me. I don't think we're doing beginners any favors if we >>>> make it easier for them to deploy sites with security issues, especially >>>> since they won't be in a good position to appreciate the consequences. >>>> Ideally we'd make it easy for beginners to deploy sites without security >>>> issues, but that's a hard problem given the diversity of production >>>> environments; in the meantime, I think we need to accept the reality that >>>> figuring out how to store secrets *is* a prerequisite to deploying Django >>>> in production, notwithstanding how much we wish it weren't. >>>> >>>> I'd be interested in trying to contribute a solution more secure than >>>> the status quo without introducing more barriers to local development, if >>>> it would have a chance of being accepted. >>>> >>>> Taymon >>>> >>>> On Friday, October 11, 2019 at 8:00:59 AM UTC-7, Carlton Gibson wrote: >>>>> >>>>> It's just scope: >>>>> >>>>> * Not clear we need to _replace_ the space for books, and blog >>>>> posts, and so on, in the main docs. >>>>> >>>>> and bandwidth: >>>>> >>>>> * These things are difficult to get right, and it needs someone to >>>>> do them. (PRs always warmly received!) >>>>> >>>>> On balance, I have to say, I think the default project template does >>>>> very well. >>>>> Taking a beginner, say, and adding, "As well as the million things >>>>> you're already dealing with, there are these things called environment >>>>> variable and..." is a step I'd be very cautious about taking. >>>>> >>>>> Yes, granted, for professional deployment, you might want different — >>>>> but we have to serve everyone. >>>>> >>>> -- >>> 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/3443dbe6-1a6a-45af-b5ec-08cf78426869%40googlegroups.com >>> <https://groups.google.com/d/msgid/django-developers/3443dbe6-1a6a-45af-b5ec-08cf78426869%40googlegroups.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/CAExk7p0%3DzRMJi1ObZnSuKncYgXVuNT-k%3DqMj5ONVuEN_nVTEQw%40mail.gmail.com >> <https://groups.google.com/d/msgid/django-developers/CAExk7p0%3DzRMJi1ObZnSuKncYgXVuNT-k%3DqMj5ONVuEN_nVTEQw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > > > -- > 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/CAMyDDM3jxm_x41otzdsqWeKG2munqrX5eqM-SG8kK_B9Y06c_w%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CAMyDDM3jxm_x41otzdsqWeKG2munqrX5eqM-SG8kK_B9Y06c_w%40mail.gmail.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/CAHRQ%3D86y-QhVj65kdi_ksSgN1ch%3DGvuxGjVZoemY0pgMmbGw1Q%40mail.gmail.com.
