Browse files

Merge pull request #253 from ubernostrum/security-documentation

Add new security-policy documentation.
  • Loading branch information...
2 parents 46cc530 + 1ef1bce commit e11e4fc1025e1ffd547bc92129109bb440b424c0 @ubernostrum ubernostrum committed Aug 7, 2012
Showing with 232 additions and 39 deletions.
  1. +9 −35 docs/internals/contributing/bugs-and-features.txt
  2. +8 −4 docs/internals/release-process.txt
  3. +215 −0 docs/internals/security.txt
@@ -2,7 +2,15 @@
Reporting bugs and requesting features
-Before reporting a bug or requesting a new feature, please consider these
+.. Important::
+ Please report security issues **only** to
+ This is a private list only open to long-time, highly trusted Django
+ developers, and its archives are not public.
+For further details, please see :doc:`our security policies </internals/security>`.
+Otherwise, before reporting a bug or requesting a new feature, please consider these
general points:
* Check that someone hasn't already filed the bug or feature request by
@@ -55,40 +63,6 @@ To understand the lifecycle of your ticket once you have created it, refer to
.. _reporting-security-issues:
-Reporting security issues
-.. Important::
- Please report security issues **only** to
- This is a private list only open to long-time, highly trusted Django
- developers, and its archives are not publicly readable.
-In the event of a confirmed vulnerability in Django itself, we will take the
-following actions:
-* Acknowledge to the reporter that we've received the report and that a
- fix is forthcoming. We'll give a rough timeline and ask the reporter
- to keep the issue confidential until we announce it.
-* Focus on developing a fix as quickly as possible and produce patches
- against the current and two previous releases.
-* Determine a go-public date for announcing the vulnerability and the fix.
- To try to mitigate a possible "arms race" between those applying the
- patch and those trying to exploit the hole, we will not announce
- security problems immediately.
-* Pre-notify third-party distributors of Django ("vendors"). We will send
- these vendor notifications through private email which will include
- documentation of the vulnerability, links to the relevant patch(es), and
- a request to keep the vulnerability confidential until the official
- go-public date.
-* Publicly announce the vulnerability and the fix on the pre-determined
- go-public date. This will probably mean a new release of Django, but
- in some cases it may simply be patches against current releases.
Reporting user interface bugs and features
@@ -31,10 +31,14 @@ Since version 1.0, Django's release numbering works as follows:
These are of the form ``A.B alpha/beta/rc N``, which means the ``Nth``
alpha/beta/release candidate of version ``A.B``.
-In Subversion, each Django release will be tagged under ``tags/releases``. If
-it's necessary to release a bug fix release or a security release that doesn't
-come from the trunk, we'll copy that tag to ``branches/releases`` to make the
-bug fix release.
+In git, each Django release will have a tag indicating its version
+number, signed with the Django release key. Additionally, each release
+series (X.Y) has its own branch, and bugfix/security releases will be
+issued from those branches.
+For more information about how the Django project issues new releases
+for security purposes, please see :doc:`our security policies
Major releases
@@ -0,0 +1,215 @@
+Django's security policies
+Django's development team is strongly committed to responsible
+reporting and disclosure of security-related issues. As such, we've
+adopted and follow a set of policies which conform to that ideal and
+are geared toward allowing us to deliver timely security updates to
+the official distribution of Django, as well as to third-party
+.. _reporting-security-issues:
+Reporting security issues
+**Short version: please report security issues by emailing**.
+Most normal bugs in Django are reported to `our public Trac
+instance`_, but due to the sensitive nature of security issues, we ask
+that they *not* be publicly reported in this fashion.
+Instead, if you believe you've found something in Django which has
+security implications, please send a description of the issue via
+email to ````. Mail sent to that address
+reaches a subset of the core development team, who can forward
+security issues into the private committers' mailing list for broader
+discussion if needed.
+You can send encrypted email to this address; the public key ID for
+```` is ``0xfcb84b8d1d17f80b``, and this
+public key is available from most commonly-used keyservers.
+Once you've submitted an issue via email, you should receive an
+acknowledgment from a member of the Django development team within 48
+hours, and depending on the action to be taken, you may receive
+further followup emails.
+.. _our public Trac instance:
+.. _security-support:
+Supported versions
+At any given time, the Django team provides official security support
+for several versions of Django:
+* The `master development branch`_, hosted on GitHub, which will
+ become the next release of Django, receives security support.
+* The two most recent Django release series receive security
+ support. For example, during the development cycle leading to the
+ release of Django 1.5, support will be provided for Django 1.4 and
+ Django 1.3. Upon the release of Django 1.5, Django 1.3's security
+ support will end.
+When new releases are issued for security reasons, the accompanying
+notice will include a list of affected versions. This list is
+comprised solely of *supported* versions of Django: older versions may
+also be affected, but we do not investigate to determine that, and
+will not issue patches or new releases for those versions.
+.. _master development branch:
+.. _security-disclosure:
+How Django discloses security issues
+Our process for taking a security issue from private discussion to
+public disclosure involves multiple steps.
+Approximately one week before full public disclosure, we will send
+advance notification of the issue to a list of people and
+organizations, primarily composed of operating-system vendors and
+other distributors of Django. This notification will consist of an
+email message, signed with the Django release key, containing:
+* A 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
+ new releases and publicy disclose the issue.
+Simultaneously, the reporter of the issue will receive notification of
+the date on which we plan to take the issue public.
+On the day of disclosure, we will take the following steps:
+1. Apply the relevant patch(es) to Django's codebase. The commit
+ messages for these patches will indicate that they are for security
+ issues, but will not describe the issue in any detail; instead,
+ they will warn of upcoming disclosure.
+2. Issue the relevant release(s), by placing new packages on `the
+ Python Package Index`_ and on the Django website, and tagging the
+ new release(s) in Django's git repository.
+3. Post a public entry on `the official Django development blog`_,
+ describing the issue and its resolution in detail, pointing to the
+ relevant patches and new releases, and crediting the reporter of
+ the issue (if the reporter wishes to be publicly identified).
+.. _the Python Package Index:
+.. _the official Django development blog:
+If a reported issue is believed to be particularly time-sensitive --
+due to a known exploit in the wild, for example -- the time between
+advance notification and public disclosure may be shortened
+Additionally, if we have reason to believe that an issue reported to
+us affects other frameworks or tools in the Python/web ecosystem, we
+may privately contact and discuss those issues with the appropriate
+maintainers, and coordinate our own disclosure and resolution with
+.. _security-notifications:
+Who receives advance notification
+The full list of people and organizations who receive advance
+notification of security issues is not and will not be made public.
+We also aim to keep this list as small as effectively possible, in
+order to better manage the flow of confidential information prior to
+disclosure. As such, our notification list is *not* simply a list of
+users of Django, and merely being a user of Django is not sufficient
+reason to be placed on the notification list.
+In broad terms, recipients of security notifications fall into three
+1. Operating-system vendors and other distributors of Django who
+ provide a suitably-generic (i.e., *not* an individual's personal
+ email address) contact address for reporting issues with their
+ Django package, or for general security reporting. In either case,
+ such addresses **must not** forward to public mailing lists or bug
+ trackers. Addresses which forward to the private email of an
+ individual maintainer or security-response contact are acceptable,
+ although private security trackers or security-response groups are
+ strongly preferred.
+2. On a case-by-case basis, individual package maintainers who have
+ demonstrated a commitment to responding to and responsibly acting
+ on these notifications.
+3. On a case-by-case basis, other entities who, in the judgment of the
+ Django development team, need to be made aware of a pending
+ security issue. Typically, membership in this group will consist of
+ some of the largest and/or most likely to be severely impacted
+ known users or distributors of Django, and will require a
+ demonstrated ability to responsibly receive, keep confidential and
+ act on these notifications.
+Additionally, a maximum of six days prior to disclosure, notification
+will be sent to the ```` mailing list, whose
+membership includes representatives of most major open-source
+operating system vendors.
+Requesting notifications
+If you believe that you, or an organization you are authorized to
+represent, fall into one of the groups listed above, you can ask to be
+added to Django's notification list by emailing
+````. Please use the subject line "Security
+notification request".
+Your request **must** include the following information:
+* Your full, real name and the name of the organization you represent,
+ if applicable, as well as your role within that organization.
+* A detailed explanation of how you or your organization fit at least
+ one set of criteria listed above.
+* A detailed explanation of why you are requesting security
+ notifications. Again, please keep in mind that this is *not* simply
+ a list for users of Django, and the overwhelming majority of users
+ of Django should not request notifications and will not be added to
+ our notification list if they do.
+* The email address you would like to have added to our notification
+ list.
+* An explanation of who will be receiving/reviewing mail sent to that
+ address, as well as information regarding any automated actions that
+ will be taken (i.e., filing of a confidential issue in a bug
+ tracker).
+* For individuals, the ID of a public key associated with your address
+ which can be used to verify email received from you and encrypt
+ email sent to you, as needed.
+Once submitted, your request will be considered by the Django
+development team; you will receive a reply notifying you of the result
+of your request within 30 days.
+Please also bear in mind that for any individual or organization,
+receiving security notifications is a privilege granted at the sole
+discretion of the Django development team, and that this privilege can
+be revoked at any time, with or without explanation.
+If you are added to the notification list, security-related emails
+will be sent to you by Django's release manager, and all notification
+emails will be signed with the same key used to sign Django releases;
+that key has the ID ``0x3684C0C08C8B2AE1``, and is available from most
+commonly-used keyservers.

0 comments on commit e11e4fc

Please sign in to comment.