Django’s development team is strongly committed to responsible\nreporting and disclosure of security-related issues. As such, we’ve\nadopted and follow a set of policies which conform to that ideal and\nare geared toward allowing us to deliver timely security updates to\nthe official distribution of Django, as well as to third-party\ndistributions.
\nShort version: please report security issues by emailing\nsecurity@djangoproject.com.
\nMost normal bugs in Django are reported to our public Trac instance, but\ndue to the sensitive nature of security issues, we ask that they not be\npublicly reported in this fashion.
\nInstead, if you believe you’ve found something in Django which has security\nimplications, please send a description of the issue via email to\nsecurity@djangoproject.com. Mail sent to that address reaches a\nsubset of the core team, who can forward security\nissues into the private committers’ mailing list for broader discussion if\nneeded.
Once you’ve submitted an issue via email, you should receive an acknowledgment\nfrom a member of the security team within 48 hours, and depending on the\naction to be taken, you may receive further followup emails.
\n\nAt any given time, the Django team provides official security support\nfor several versions of Django:
\nThe master development branch, hosted on GitHub, which will\nbecome the next release of Django, receives security support.
The two most recent Django release series receive security\nsupport. For example, during the development cycle leading to the\nrelease of Django 1.5, support will be provided for Django 1.4 and\nDjango 1.3. Upon the release of Django 1.5, Django 1.3’s security\nsupport will end.
Long-term support releases will receive security updates for a\nspecified period.
When new releases are issued for security reasons, the accompanying\nnotice will include a list of affected versions. This list is\ncomprised solely of supported versions of Django: older versions may\nalso be affected, but we do not investigate to determine that, and\nwill not issue patches or new releases for those versions.
\nOur process for taking a security issue from private discussion to\npublic disclosure involves multiple steps.
\nApproximately one week before full public disclosure, we will send\nadvance notification of the issue to a list of people and\norganizations, primarily composed of operating-system vendors and\nother distributors of Django. This notification will consist of an\nemail message, signed with the Django release key, containing:
\nA full description of the issue and the affected versions of Django.
The steps we will be taking to remedy the issue.
The patch(es), if any, that will be applied to Django.
The date on which the Django team will apply these patches, issue\nnew releases and publicly disclose the issue.
Simultaneously, the reporter of the issue will receive notification of\nthe date on which we plan to take the issue public.
\nOn the day of disclosure, we will take the following steps:
\nApply the relevant patch(es) to Django’s codebase. The commit\nmessages for these patches will indicate that they are for security\nissues, but will not describe the issue in any detail; instead,\nthey will warn of upcoming disclosure.
Issue the relevant release(s), by placing new packages on the\nPython Package Index and on the Django website, and tagging the\nnew release(s) in Django’s git repository.
Post a public entry on the official Django development blog,\ndescribing the issue and its resolution in detail, pointing to the\nrelevant patches and new releases, and crediting the reporter of\nthe issue (if the reporter wishes to be publicly identified).
Post a notice to the django-announce and oss-security@lists.openwall.com\nmailing lists that links to the blog post.
If a reported issue is believed to be particularly time-sensitive –\ndue to a known exploit in the wild, for example – the time between\nadvance notification and public disclosure may be shortened\nconsiderably.
\nAdditionally, if we have reason to believe that an issue reported to\nus affects other frameworks or tools in the Python/web ecosystem, we\nmay privately contact and discuss those issues with the appropriate\nmaintainers, and coordinate our own disclosure and resolution with\ntheirs.
\nThe Django team also maintains an archive of security issues\ndisclosed in Django.
\nThe full list of people and organizations who receive advance\nnotification of security issues is not and will not be made public.
\nWe also aim to keep this list as small as effectively possible, in\norder to better manage the flow of confidential information prior to\ndisclosure. As such, our notification list is not simply a list of\nusers of Django, and merely being a user of Django is not sufficient\nreason to be placed on the notification list.
\nIn broad terms, recipients of security notifications fall into three\ngroups:
\nOperating-system vendors and other distributors of Django who\nprovide a suitably-generic (i.e., not an individual’s personal\nemail address) contact address for reporting issues with their\nDjango package, or for general security reporting. In either case,\nsuch addresses must not forward to public mailing lists or bug\ntrackers. Addresses which forward to the private email of an\nindividual maintainer or security-response contact are acceptable,\nalthough private security trackers or security-response groups are\nstrongly preferred.
On a case-by-case basis, individual package maintainers who have\ndemonstrated a commitment to responding to and responsibly acting\non these notifications.
On a case-by-case basis, other entities who, in the judgment of the\nDjango development team, need to be made aware of a pending\nsecurity issue. Typically, membership in this group will consist of\nsome of the largest and/or most likely to be severely impacted\nknown users or distributors of Django, and will require a\ndemonstrated ability to responsibly receive, keep confidential and\nact on these notifications.
If you believe that you, or an organization you are authorized to\nrepresent, fall into one of the groups listed above, you can ask to be\nadded to Django’s notification list by emailing\nsecurity@djangoproject.com. Please use the subject line “Security\nnotification request”.
Your request must include the following information:
\nYour full, real name and the name of the organization you represent,\nif applicable, as well as your role within that organization.
A detailed explanation of how you or your organization fit at least\none set of criteria listed above.
A detailed explanation of why you are requesting security\nnotifications. Again, please keep in mind that this is not simply\na list for users of Django, and the overwhelming majority of users\nof Django should not request notifications and will not be added to\nour notification list if they do.
The email address you would like to have added to our notification\nlist.
An explanation of who will be receiving/reviewing mail sent to that\naddress, as well as information regarding any automated actions that\nwill be taken (i.e., filing of a confidential issue in a bug\ntracker).
For individuals, the ID of a public key associated with your address\nwhich can be used to verify email received from you and encrypt\nemail sent to you, as needed.
Once submitted, your request will be considered by the Django\ndevelopment team; you will receive a reply notifying you of the result\nof your request within 30 days.
\nPlease also bear in mind that for any individual or organization,\nreceiving security notifications is a privilege granted at the sole\ndiscretion of the Django development team, and that this privilege can\nbe revoked at any time, with or without explanation.
\nIf you are added to the notification list, security-related emails\nwill be sent to you by Django’s release team, and all notification\nemails will be signed with a key authorized to issue Django\nreleases. The list of authorized keys is in the Django releasers\nfile.
\n