Merge pull request #253 from ubernostrum/security-documentation

Add new security-policy documentation.

docs/internals/contributing/bugs-and-features.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 security@djangoproject.com.
+    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 security@djangoproject.com.
-    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
 ------------------------------------------
 

docs/internals/release-process.txt

@@ -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
+<security>`.
 
 Major releases
 --------------

docs/internals/security.txt

@@ -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
+distributions.
+
+.. _reporting-security-issues:
+
+Reporting security issues
+=========================
+
+**Short version: please report security issues by emailing
+security@djangoproject.com**.
+
+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 ``security@djangoproject.com``. 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
+``security@djangoproject.com`` 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: https://code.djangoproject.com/query
+
+.. _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: https://github.com/django/django/
+
+.. _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: http://pypi.python.org/pypi
+.. _the official Django development blog: https://www.djangoproject.com/weblog/
+
+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
+considerably.
+
+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
+theirs.
+
+.. _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
+groups:
+
+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 ``distros@vs.openwall.org`` 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
+``security@djangoproject.com``. 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.