mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-08-31 07:47:37 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 2

Add new security-policy documentation.

Browse source 
This formally describes our policies on reporting, notification and
disclosure of security issues, and provides a detailed explanation of
our full security-response process, for reference purposes.
This commit is contained in:
James Bennett 2012-08-07 16:06:34 -04:00
parent 46cc530fad
commit 1ef1bceb3b
3 changed files with 232 additions and 39 deletions
Download patch file Download diff file Expand all files Collapse all files

44
docs/internals/contributing/bugs-and-features.txt
View file

@ -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
------------------------------------------