Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse code

Merge pull request #253 from ubernostrum/security-documentation

Add new security-policy documentation.
  • Loading branch information...
commit e11e4fc1025e1ffd547bc92129109bb440b424c0 2 parents 46cc530 + 1ef1bce
James Bennett authored August 07, 2012
44  docs/internals/contributing/bugs-and-features.txt
@@ -2,7 +2,15 @@
2 2
 Reporting bugs and requesting features
3 3
 ======================================
4 4
 
5  
-Before reporting a bug or requesting a new feature, please consider these
  5
+.. Important::
  6
+
  7
+    Please report security issues **only** to security@djangoproject.com.
  8
+    This is a private list only open to long-time, highly trusted Django
  9
+    developers, and its archives are not public.
  10
+
  11
+For further details, please see :doc:`our security policies </internals/security>`.
  12
+
  13
+Otherwise, before reporting a bug or requesting a new feature, please consider these
6 14
 general points:
7 15
 
8 16
 * 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
55 63
 
56 64
 .. _reporting-security-issues:
57 65
 
58  
-Reporting security issues
59  
--------------------------
60  
-
61  
-.. Important::
62  
-
63  
-    Please report security issues **only** to security@djangoproject.com.
64  
-    This is a private list only open to long-time, highly trusted Django
65  
-    developers, and its archives are not publicly readable.
66  
-
67  
-In the event of a confirmed vulnerability in Django itself, we will take the
68  
-following actions:
69  
-
70  
-* Acknowledge to the reporter that we've received the report and that a
71  
-  fix is forthcoming. We'll give a rough timeline and ask the reporter
72  
-  to keep the issue confidential until we announce it.
73  
-
74  
-* Focus on developing a fix as quickly as possible and produce patches
75  
-  against the current and two previous releases.
76  
-
77  
-* Determine a go-public date for announcing the vulnerability and the fix.
78  
-  To try to mitigate a possible "arms race" between those applying the
79  
-  patch and those trying to exploit the hole, we will not announce
80  
-  security problems immediately.
81  
-
82  
-* Pre-notify third-party distributors of Django ("vendors"). We will send
83  
-  these vendor notifications through private email which will include
84  
-  documentation of the vulnerability, links to the relevant patch(es), and
85  
-  a request to keep the vulnerability confidential until the official
86  
-  go-public date.
87  
-
88  
-* Publicly announce the vulnerability and the fix on the pre-determined
89  
-  go-public date. This will probably mean a new release of Django, but
90  
-  in some cases it may simply be patches against current releases.
91  
-
92 66
 Reporting user interface bugs and features
93 67
 ------------------------------------------
94 68
 
12  docs/internals/release-process.txt
@@ -31,10 +31,14 @@ Since version 1.0, Django's release numbering works as follows:
31 31
   These are of the form ``A.B alpha/beta/rc N``, which means the ``Nth``
32 32
   alpha/beta/release candidate of version ``A.B``.
33 33
 
34  
-In Subversion, each Django release will be tagged under ``tags/releases``.  If
35  
-it's necessary to release a bug fix release or a security release that doesn't
36  
-come from the trunk, we'll copy that tag to ``branches/releases`` to make the
37  
-bug fix release.
  34
+In git, each Django release will have a tag indicating its version
  35
+number, signed with the Django release key. Additionally, each release
  36
+series (X.Y) has its own branch, and bugfix/security releases will be
  37
+issued from those branches.
  38
+
  39
+For more information about how the Django project issues new releases
  40
+for security purposes, please see :doc:`our security policies
  41
+<security>`.
38 42
 
39 43
 Major releases
40 44
 --------------
215  docs/internals/security.txt
... ...
@@ -0,0 +1,215 @@
  1
+==========================
  2
+Django's security policies
  3
+==========================
  4
+
  5
+Django's development team is strongly committed to responsible
  6
+reporting and disclosure of security-related issues. As such, we've
  7
+adopted and follow a set of policies which conform to that ideal and
  8
+are geared toward allowing us to deliver timely security updates to
  9
+the official distribution of Django, as well as to third-party
  10
+distributions.
  11
+
  12
+.. _reporting-security-issues:
  13
+
  14
+Reporting security issues
  15
+=========================
  16
+
  17
+**Short version: please report security issues by emailing
  18
+security@djangoproject.com**.
  19
+
  20
+Most normal bugs in Django are reported to `our public Trac
  21
+instance`_, but due to the sensitive nature of security issues, we ask
  22
+that they *not* be publicly reported in this fashion.
  23
+
  24
+Instead, if you believe you've found something in Django which has
  25
+security implications, please send a description of the issue via
  26
+email to ``security@djangoproject.com``. Mail sent to that address
  27
+reaches a subset of the core development team, who can forward
  28
+security issues into the private committers' mailing list for broader
  29
+discussion if needed.
  30
+
  31
+You can send encrypted email to this address; the public key ID for
  32
+``security@djangoproject.com`` is ``0xfcb84b8d1d17f80b``, and this
  33
+public key is available from most commonly-used keyservers.
  34
+
  35
+Once you've submitted an issue via email, you should receive an
  36
+acknowledgment from a member of the Django development team within 48
  37
+hours, and depending on the action to be taken, you may receive
  38
+further followup emails.
  39
+
  40
+.. _our public Trac instance: https://code.djangoproject.com/query
  41
+
  42
+.. _security-support:
  43
+
  44
+Supported versions
  45
+==================
  46
+
  47
+At any given time, the Django team provides official security support
  48
+for several versions of Django:
  49
+
  50
+* The `master development branch`_, hosted on GitHub, which will
  51
+  become the next release of Django, receives security support.
  52
+
  53
+* The two most recent Django release series receive security
  54
+  support. For example, during the development cycle leading to the
  55
+  release of Django 1.5, support will be provided for Django 1.4 and
  56
+  Django 1.3. Upon the release of Django 1.5, Django 1.3's security
  57
+  support will end.
  58
+
  59
+When new releases are issued for security reasons, the accompanying
  60
+notice will include a list of affected versions. This list is
  61
+comprised solely of *supported* versions of Django: older versions may
  62
+also be affected, but we do not investigate to determine that, and
  63
+will not issue patches or new releases for those versions.
  64
+
  65
+.. _master development branch: https://github.com/django/django/
  66
+
  67
+.. _security-disclosure:
  68
+
  69
+How Django discloses security issues
  70
+====================================
  71
+
  72
+Our process for taking a security issue from private discussion to
  73
+public disclosure involves multiple steps.
  74
+
  75
+Approximately one week before full public disclosure, we will send
  76
+advance notification of the issue to a list of people and
  77
+organizations, primarily composed of operating-system vendors and
  78
+other distributors of Django. This notification will consist of an
  79
+email message, signed with the Django release key, containing:
  80
+
  81
+* A full description of the issue and the affected versions of Django.
  82
+
  83
+* The steps we will be taking to remedy the issue.
  84
+
  85
+* The patch(es), if any, that will be applied to Django.
  86
+
  87
+* The date on which the Django team will apply these patches, issue
  88
+  new releases and publicy disclose the issue.
  89
+
  90
+Simultaneously, the reporter of the issue will receive notification of
  91
+the date on which we plan to take the issue public.
  92
+
  93
+On the day of disclosure, we will take the following steps:
  94
+
  95
+1. Apply the relevant patch(es) to Django's codebase. The commit
  96
+   messages for these patches will indicate that they are for security
  97
+   issues, but will not describe the issue in any detail; instead,
  98
+   they will warn of upcoming disclosure.
  99
+
  100
+2. Issue the relevant release(s), by placing new packages on `the
  101
+   Python Package Index`_ and on the Django website, and tagging the
  102
+   new release(s) in Django's git repository.
  103
+
  104
+3. Post a public entry on `the official Django development blog`_,
  105
+   describing the issue and its resolution in detail, pointing to the
  106
+   relevant patches and new releases, and crediting the reporter of
  107
+   the issue (if the reporter wishes to be publicly identified).
  108
+
  109
+.. _the Python Package Index: http://pypi.python.org/pypi
  110
+.. _the official Django development blog: https://www.djangoproject.com/weblog/
  111
+
  112
+If a reported issue is believed to be particularly time-sensitive --
  113
+due to a known exploit in the wild, for example -- the time between
  114
+advance notification and public disclosure may be shortened
  115
+considerably.
  116
+
  117
+Additionally, if we have reason to believe that an issue reported to
  118
+us affects other frameworks or tools in the Python/web ecosystem, we
  119
+may privately contact and discuss those issues with the appropriate
  120
+maintainers, and coordinate our own disclosure and resolution with
  121
+theirs.
  122
+
  123
+.. _security-notifications:
  124
+
  125
+Who receives advance notification
  126
+=================================
  127
+
  128
+The full list of people and organizations who receive advance
  129
+notification of security issues is not and will not be made public.
  130
+
  131
+We also aim to keep this list as small as effectively possible, in
  132
+order to better manage the flow of confidential information prior to
  133
+disclosure. As such, our notification list is *not* simply a list of
  134
+users of Django, and merely being a user of Django is not sufficient
  135
+reason to be placed on the notification list.
  136
+
  137
+In broad terms, recipients of security notifications fall into three
  138
+groups:
  139
+
  140
+1. Operating-system vendors and other distributors of Django who
  141
+   provide a suitably-generic (i.e., *not* an individual's personal
  142
+   email address) contact address for reporting issues with their
  143
+   Django package, or for general security reporting. In either case,
  144
+   such addresses **must not** forward to public mailing lists or bug
  145
+   trackers. Addresses which forward to the private email of an
  146
+   individual maintainer or security-response contact are acceptable,
  147
+   although private security trackers or security-response groups are
  148
+   strongly preferred.
  149
+
  150
+2. On a case-by-case basis, individual package maintainers who have
  151
+   demonstrated a commitment to responding to and responsibly acting
  152
+   on these notifications.
  153
+
  154
+3. On a case-by-case basis, other entities who, in the judgment of the
  155
+   Django development team, need to be made aware of a pending
  156
+   security issue. Typically, membership in this group will consist of
  157
+   some of the largest and/or most likely to be severely impacted
  158
+   known users or distributors of Django, and will require a
  159
+   demonstrated ability to responsibly receive, keep confidential and
  160
+   act on these notifications.
  161
+
  162
+Additionally, a maximum of six days prior to disclosure, notification
  163
+will be sent to the ``distros@vs.openwall.org`` mailing list, whose
  164
+membership includes representatives of most major open-source
  165
+operating system vendors.
  166
+
  167
+Requesting notifications
  168
+========================
  169
+
  170
+If you believe that you, or an organization you are authorized to
  171
+represent, fall into one of the groups listed above, you can ask to be
  172
+added to Django's notification list by emailing
  173
+``security@djangoproject.com``. Please use the subject line "Security
  174
+notification request".
  175
+
  176
+Your request **must** include the following information:
  177
+
  178
+* Your full, real name and the name of the organization you represent,
  179
+  if applicable, as well as your role within that organization.
  180
+
  181
+* A detailed explanation of how you or your organization fit at least
  182
+  one set of criteria listed above.
  183
+
  184
+* A detailed explanation of why you are requesting security
  185
+  notifications. Again, please keep in mind that this is *not* simply
  186
+  a list for users of Django, and the overwhelming majority of users
  187
+  of Django should not request notifications and will not be added to
  188
+  our notification list if they do.
  189
+
  190
+* The email address you would like to have added to our notification
  191
+  list.
  192
+
  193
+* An explanation of who will be receiving/reviewing mail sent to that
  194
+  address, as well as information regarding any automated actions that
  195
+  will be taken (i.e., filing of a confidential issue in a bug
  196
+  tracker).
  197
+
  198
+* For individuals, the ID of a public key associated with your address
  199
+  which can be used to verify email received from you and encrypt
  200
+  email sent to you, as needed.
  201
+
  202
+Once submitted, your request will be considered by the Django
  203
+development team; you will receive a reply notifying you of the result
  204
+of your request within 30 days.
  205
+
  206
+Please also bear in mind that for any individual or organization,
  207
+receiving security notifications is a privilege granted at the sole
  208
+discretion of the Django development team, and that this privilege can
  209
+be revoked at any time, with or without explanation.
  210
+
  211
+If you are added to the notification list, security-related emails
  212
+will be sent to you by Django's release manager, and all notification
  213
+emails will be signed with the same key used to sign Django releases;
  214
+that key has the ID ``0x3684C0C08C8B2AE1``, and is available from most
  215
+commonly-used keyservers.

0 notes on commit e11e4fc

Please sign in to comment.
Something went wrong with that request. Please try again.