forked from django/django
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Added missing release notes for older versions of Django
- Loading branch information
Showing
10 changed files
with
373 additions
and
4 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,11 @@ | ||
========================== | ||
Django 1.3.3 release notes | ||
========================== | ||
|
||
*August 1, 2012* | ||
|
||
Following Monday's security release of :doc:`Django 1.3.2 </releases/1.3.2>`, | ||
we began receiving reports that one of the fixes applied was breaking Python | ||
2.4 compatibility for Django 1.3. Since Python 2.4 is a supported Python | ||
version for that release series, this release fixes compatibility with | ||
Python 2.4. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,37 @@ | ||
========================== | ||
Django 1.3.4 release notes | ||
========================== | ||
|
||
*October 17, 2012* | ||
|
||
This is the fourth release in the Django 1.3 series. | ||
|
||
Host header poisoning | ||
--------------------- | ||
|
||
Some parts of Django -- independent of end-user-written applications -- make | ||
use of full URLs, including domain name, which are generated from the HTTP Host | ||
header. Some attacks against this are beyond Django's ability to control, and | ||
require the web server to be properly configured; Django's documentation has | ||
for some time contained notes advising users on such configuration. | ||
|
||
Django's own built-in parsing of the Host header is, however, still vulnerable, | ||
as was reported to us recently. The Host header parsing in Django 1.3.3 and | ||
Django 1.4.1 -- specifically, ``django.http.HttpRequest.get_host()`` -- was | ||
incorrectly handling username/password information in the header. Thus, for | ||
example, the following Host header would be accepted by Django when running on | ||
"validsite.com":: | ||
|
||
Host: validsite.com:random@evilsite.com | ||
|
||
Using this, an attacker can cause parts of Django -- particularly the | ||
password-reset mechanism -- to generate and display arbitrary URLs to users. | ||
|
||
To remedy this, the parsing in ``HttpRequest.get_host()`` is being modified; | ||
Host headers which contain potentially dangerous content (such as | ||
username/password pairs) now raise the exception | ||
:exc:`django.core.exceptions.SuspiciousOperation`. | ||
|
||
Details of this issue were initially posted online as a `security advisory`_. | ||
|
||
.. _security advisory: https://www.djangoproject.com/weblog/2012/oct/17/security/ |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,60 @@ | ||
========================== | ||
Django 1.3.5 release notes | ||
========================== | ||
|
||
*December 10, 2012* | ||
|
||
Django 1.3.5 addresses two security issues present in previous Django releases | ||
in the 1.3 series. | ||
|
||
Please be aware that this security release is slightly different from previous | ||
ones. Both issues addressed here have been dealt with in prior security updates | ||
to Django. In one case, we have received ongoing reports of problems, and in | ||
the other we've chosen to take further steps to tighten up Django's code in | ||
response to independent discovery of potential problems from multiple sources. | ||
|
||
Host header poisoning | ||
--------------------- | ||
|
||
Several earlier Django security releases focused on the issue of poisoning the | ||
HTTP Host header, causing Django to generate URLs pointing to arbitrary, | ||
potentially-malicious domains. | ||
|
||
In response to further input received and reports of continuing issues | ||
following the previous release, we're taking additional steps to tighten Host | ||
header validation. Rather than attempt to accommodate all features HTTP | ||
supports here, Django's Host header validation attempts to support a smaller, | ||
but far more common, subset: | ||
|
||
* Hostnames must consist of characters [A-Za-z0-9] plus hyphen ('-') or dot | ||
('.'). | ||
* IP addresses -- both IPv4 and IPv6 -- are permitted. | ||
* Port, if specified, is numeric. | ||
|
||
Any deviation from this will now be rejected, raising the exception | ||
:exc:`django.core.exceptions.SuspiciousOperation`. | ||
|
||
Redirect poisoning | ||
------------------ | ||
|
||
Also following up on a previous issue: in July of this year, we made changes to | ||
Django's HTTP redirect classes, performing additional validation of the scheme | ||
of the URL to redirect to (since, both within Django's own supplied | ||
applications and many third-party applications, accepting a user-supplied | ||
redirect target is a common pattern). | ||
|
||
Since then, two independent audits of the code turned up further potential | ||
problems. So, similar to the Host-header issue, we are taking steps to provide | ||
tighter validation in response to reported problems (primarily with third-party | ||
applications, but to a certain extent also within Django itself). This comes in | ||
two parts: | ||
|
||
1. A new utility function, ``django.utils.http.is_safe_url``, is added; this | ||
function takes a URL and a hostname, and checks that the URL is either | ||
relative, or if absolute matches the supplied hostname. This function is | ||
intended for use whenever user-supplied redirect targets are accepted, to | ||
ensure that such redirects cannot lead to arbitrary third-party sites. | ||
|
||
2. All of Django's own built-in views -- primarily in the authentication system | ||
-- which allow user-supplied redirect targets now use ``is_safe_url`` to | ||
validate the supplied URL. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,78 @@ | ||
========================== | ||
Django 1.3.6 release notes | ||
========================== | ||
|
||
*February 19, 2013* | ||
|
||
Django 1.3.6 fixes four security issues present in previous Django releases in | ||
the 1.3 series. | ||
|
||
This is the sixth bugfix/security release in the Django 1.3 series. | ||
|
||
|
||
Host header poisoning | ||
--------------------- | ||
|
||
Some parts of Django -- independent of end-user-written applications -- make | ||
use of full URLs, including domain name, which are generated from the HTTP Host | ||
header. Django's documentation has for some time contained notes advising users | ||
on how to configure webservers to ensure that only valid Host headers can reach | ||
the Django application. However, it has been reported to us that even with the | ||
recommended webserver configurations there are still techniques available for | ||
tricking many common webservers into supplying the application with an | ||
incorrect and possibly malicious Host header. | ||
|
||
For this reason, Django 1.3.6 adds a new setting, ``ALLOWED_HOSTS``, which | ||
should contain an explicit list of valid host/domain names for this site. A | ||
request with a Host header not matching an entry in this list will raise | ||
``SuspiciousOperation`` if ``request.get_host()`` is called. For full details | ||
see the documentation for the :setting:`ALLOWED_HOSTS` setting. | ||
|
||
The default value for this setting in Django 1.3.6 is ``['*']`` (matching any | ||
host), for backwards-compatibility, but we strongly encourage all sites to set | ||
a more restrictive value. | ||
|
||
This host validation is disabled when ``DEBUG`` is ``True`` or when running tests. | ||
|
||
|
||
XML deserialization | ||
------------------- | ||
|
||
The XML parser in the Python standard library is vulnerable to a number of | ||
attacks via external entities and entity expansion. Django uses this parser for | ||
deserializing XML-formatted database fixtures. The fixture deserializer is not | ||
intended for use with untrusted data, but in order to err on the side of safety | ||
in Django 1.3.6 the XML deserializer refuses to parse an XML document with a | ||
DTD (DOCTYPE definition), which closes off these attack avenues. | ||
|
||
These issues in the Python standard library are CVE-2013-1664 and | ||
CVE-2013-1665. More information available `from the Python security team`_. | ||
|
||
Django's XML serializer does not create documents with a DTD, so this should | ||
not cause any issues with the typical round-trip from ``dumpdata`` to | ||
``loaddata``, but if you feed your own XML documents to the ``loaddata`` | ||
management command, you will need to ensure they do not contain a DTD. | ||
|
||
.. _from the Python security team: http://blog.python.org/2013/02/announcing-defusedxml-fixes-for-xml.html | ||
|
||
|
||
Formset memory exhaustion | ||
------------------------- | ||
|
||
Previous versions of Django did not validate or limit the form-count data | ||
provided by the client in a formset's management form, making it possible to | ||
exhaust a server's available memory by forcing it to create very large numbers | ||
of forms. | ||
|
||
In Django 1.3.6, all formsets have a strictly-enforced maximum number of forms | ||
(1000 by default, though it can be set higher via the ``max_num`` formset | ||
factory argument). | ||
|
||
|
||
Admin history view information leakage | ||
-------------------------------------- | ||
|
||
In previous versions of Django, an admin user without change permission on a | ||
model could still view the unicode representation of instances via their admin | ||
history log. Django 1.3.6 now limits the admin history log view for an object | ||
to users with change permission for that model. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,13 @@ | ||
========================== | ||
Django 1.3.7 release notes | ||
========================== | ||
|
||
*February 20, 2013* | ||
|
||
Django 1.3.7 corrects a packaging problem with yesterday's :doc:`1.3.6 release | ||
</releases/1.3.6>`. | ||
|
||
The release contained stray ``.pyc`` files that caused "bad magic number" | ||
errors when running with some versions of Python. This releases corrects this, | ||
and also fixes a bad documentation link in the project template ``settings.py`` | ||
file generated by ``manage.py startproject``. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,60 @@ | ||
========================== | ||
Django 1.4.3 release notes | ||
========================== | ||
|
||
*December 10, 2012* | ||
|
||
Django 1.4.3 addresses two security issues present in previous Django releases | ||
in the 1.4 series. | ||
|
||
Please be aware that this security release is slightly different from previous | ||
ones. Both issues addressed here have been dealt with in prior security updates | ||
to Django. In one case, we have received ongoing reports of problems, and in | ||
the other we've chosen to take further steps to tighten up Django's code in | ||
response to independent discovery of potential problems from multiple sources. | ||
|
||
Host header poisoning | ||
--------------------- | ||
|
||
Several earlier Django security releases focused on the issue of poisoning the | ||
HTTP Host header, causing Django to generate URLs pointing to arbitrary, | ||
potentially-malicious domains. | ||
|
||
In response to further input received and reports of continuing issues | ||
following the previous release, we're taking additional steps to tighten Host | ||
header validation. Rather than attempt to accommodate all features HTTP | ||
supports here, Django's Host header validation attempts to support a smaller, | ||
but far more common, subset: | ||
|
||
* Hostnames must consist of characters [A-Za-z0-9] plus hyphen ('-') or dot | ||
('.'). | ||
* IP addresses -- both IPv4 and IPv6 -- are permitted. | ||
* Port, if specified, is numeric. | ||
|
||
Any deviation from this will now be rejected, raising the exception | ||
:exc:`django.core.exceptions.SuspiciousOperation`. | ||
|
||
Redirect poisoning | ||
------------------ | ||
|
||
Also following up on a previous issue: in July of this year, we made changes to | ||
Django's HTTP redirect classes, performing additional validation of the scheme | ||
of the URL to redirect to (since, both within Django's own supplied | ||
applications and many third-party applications, accepting a user-supplied | ||
redirect target is a common pattern). | ||
|
||
Since then, two independent audits of the code turned up further potential | ||
problems. So, similar to the Host-header issue, we are taking steps to provide | ||
tighter validation in response to reported problems (primarily with third-party | ||
applications, but to a certain extent also within Django itself). This comes in | ||
two parts: | ||
|
||
1. A new utility function, ``django.utils.http.is_safe_url``, is added; this | ||
function takes a URL and a hostname, and checks that the URL is either | ||
relative, or if absolute matches the supplied hostname. This function is | ||
intended for use whenever user-supplied redirect targets are accepted, to | ||
ensure that such redirects cannot lead to arbitrary third-party sites. | ||
|
||
2. All of Django's own built-in views -- primarily in the authentication system | ||
-- which allow user-supplied redirect targets now use ``is_safe_url`` to | ||
validate the supplied URL. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,88 @@ | ||
========================== | ||
Django 1.4.4 release notes | ||
========================== | ||
|
||
*February 19, 2013* | ||
|
||
Django 1.4.4 fixes four security issues present in previous Django releases in | ||
the 1.4 series, as well as several other bugs and numerous documentation | ||
improvements. | ||
|
||
This is the fourth bugfix/security release in the Django 1.4 series. | ||
|
||
|
||
Host header poisoning | ||
--------------------- | ||
|
||
Some parts of Django -- independent of end-user-written applications -- make | ||
use of full URLs, including domain name, which are generated from the HTTP Host | ||
header. Django's documentation has for some time contained notes advising users | ||
on how to configure webservers to ensure that only valid Host headers can reach | ||
the Django application. However, it has been reported to us that even with the | ||
recommended webserver configurations there are still techniques available for | ||
tricking many common webservers into supplying the application with an | ||
incorrect and possibly malicious Host header. | ||
|
||
For this reason, Django 1.4.4 adds a new setting, ``ALLOWED_HOSTS``, containing | ||
an explicit list of valid host/domain names for this site. A request with a | ||
Host header not matching an entry in this list will raise | ||
``SuspiciousOperation`` if ``request.get_host()`` is called. For full details | ||
see the documentation for the :setting:`ALLOWED_HOSTS` setting. | ||
|
||
The default value for this setting in Django 1.4.4 is ``['*']`` (matching any | ||
host), for backwards-compatibility, but we strongly encourage all sites to set | ||
a more restrictive value. | ||
|
||
This host validation is disabled when ``DEBUG`` is ``True`` or when running tests. | ||
|
||
|
||
XML deserialization | ||
------------------- | ||
|
||
The XML parser in the Python standard library is vulnerable to a number of | ||
attacks via external entities and entity expansion. Django uses this parser for | ||
deserializing XML-formatted database fixtures. This deserializer is not | ||
intended for use with untrusted data, but in order to err on the side of safety | ||
in Django 1.4.4 the XML deserializer refuses to parse an XML document with a | ||
DTD (DOCTYPE definition), which closes off these attack avenues. | ||
|
||
These issues in the Python standard library are CVE-2013-1664 and | ||
CVE-2013-1665. More information available `from the Python security team`_. | ||
|
||
Django's XML serializer does not create documents with a DTD, so this should | ||
not cause any issues with the typical round-trip from ``dumpdata`` to | ||
``loaddata``, but if you feed your own XML documents to the ``loaddata`` | ||
management command, you will need to ensure they do not contain a DTD. | ||
|
||
.. _from the Python security team: http://blog.python.org/2013/02/announcing-defusedxml-fixes-for-xml.html | ||
|
||
|
||
Formset memory exhaustion | ||
------------------------- | ||
|
||
Previous versions of Django did not validate or limit the form-count data | ||
provided by the client in a formset's management form, making it possible to | ||
exhaust a server's available memory by forcing it to create very large numbers | ||
of forms. | ||
|
||
In Django 1.4.4, all formsets have a strictly-enforced maximum number of forms | ||
(1000 by default, though it can be set higher via the ``max_num`` formset | ||
factory argument). | ||
|
||
|
||
Admin history view information leakage | ||
-------------------------------------- | ||
|
||
In previous versions of Django, an admin user without change permission on a | ||
model could still view the unicode representation of instances via their admin | ||
history log. Django 1.4.4 now limits the admin history log view for an object | ||
to users with change permission for that model. | ||
|
||
|
||
Other bugfixes and changes | ||
========================== | ||
|
||
* Prevented transaction state from leaking from one request to the next (#19707). | ||
* Changed a SQL command syntax to be MySQL 4 compatible (#19702). | ||
* Added backwards-compatibility with old unsalted MD5 passwords (#18144). | ||
* Numerous documentation improvements and fixes. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,13 @@ | ||
========================== | ||
Django 1.4.5 release notes | ||
========================== | ||
|
||
*February 20, 2013* | ||
|
||
Django 1.4.5 corrects a packaging problem with yesterday's :doc:`1.4.4 release | ||
</releases/1.4.4>`. | ||
|
||
The release contained stray ``.pyc`` files that caused "bad magic number" | ||
errors when running with some versions of Python. This releases corrects this, | ||
and also fixes a bad documentation link in the project template ``settings.py`` | ||
file generated by ``manage.py startproject``. |
Oops, something went wrong.