From 4f470f5186d4c61a4b1c95bb9346d03b7c2f3aca Mon Sep 17 00:00:00 2001 From: Tim Graham Date: Mon, 12 Aug 2013 13:20:58 -0400 Subject: [PATCH] [1.6.x] Added missing release notes for older versions of Django Backport of 3f6cc33cff from master --- docs/releases/1.3.3.txt | 11 ++++++ docs/releases/1.3.4.txt | 37 +++++++++++++++++ docs/releases/1.3.5.txt | 60 ++++++++++++++++++++++++++++ docs/releases/1.3.6.txt | 78 ++++++++++++++++++++++++++++++++++++ docs/releases/1.3.7.txt | 13 ++++++ docs/releases/1.4.2.txt | 9 +++-- docs/releases/1.4.3.txt | 60 ++++++++++++++++++++++++++++ docs/releases/1.4.4.txt | 88 +++++++++++++++++++++++++++++++++++++++++ docs/releases/1.4.5.txt | 13 ++++++ docs/releases/index.txt | 8 ++++ 10 files changed, 373 insertions(+), 4 deletions(-) create mode 100644 docs/releases/1.3.3.txt create mode 100644 docs/releases/1.3.4.txt create mode 100644 docs/releases/1.3.5.txt create mode 100644 docs/releases/1.3.6.txt create mode 100644 docs/releases/1.3.7.txt create mode 100644 docs/releases/1.4.3.txt create mode 100644 docs/releases/1.4.4.txt create mode 100644 docs/releases/1.4.5.txt diff --git a/docs/releases/1.3.3.txt b/docs/releases/1.3.3.txt new file mode 100644 index 0000000000..437cbfb412 --- /dev/null +++ b/docs/releases/1.3.3.txt @@ -0,0 +1,11 @@ +========================== +Django 1.3.3 release notes +========================== + +*August 1, 2012* + +Following Monday's security release of :doc:`Django 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. diff --git a/docs/releases/1.3.4.txt b/docs/releases/1.3.4.txt new file mode 100644 index 0000000000..3a174b3d44 --- /dev/null +++ b/docs/releases/1.3.4.txt @@ -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/ diff --git a/docs/releases/1.3.5.txt b/docs/releases/1.3.5.txt new file mode 100644 index 0000000000..65c403209d --- /dev/null +++ b/docs/releases/1.3.5.txt @@ -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. diff --git a/docs/releases/1.3.6.txt b/docs/releases/1.3.6.txt new file mode 100644 index 0000000000..d55199a882 --- /dev/null +++ b/docs/releases/1.3.6.txt @@ -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. diff --git a/docs/releases/1.3.7.txt b/docs/releases/1.3.7.txt new file mode 100644 index 0000000000..3cccfcfb1c --- /dev/null +++ b/docs/releases/1.3.7.txt @@ -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 +`. + +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``. diff --git a/docs/releases/1.4.2.txt b/docs/releases/1.4.2.txt index 07eec39764..a6150f56c3 100644 --- a/docs/releases/1.4.2.txt +++ b/docs/releases/1.4.2.txt @@ -17,7 +17,7 @@ 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 +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":: @@ -27,9 +27,10 @@ example, the following Host header would be accepted by Django when running on 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 django.core.exceptions.SuspiciousOperation +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`_. diff --git a/docs/releases/1.4.3.txt b/docs/releases/1.4.3.txt new file mode 100644 index 0000000000..aadf623c3c --- /dev/null +++ b/docs/releases/1.4.3.txt @@ -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. diff --git a/docs/releases/1.4.4.txt b/docs/releases/1.4.4.txt new file mode 100644 index 0000000000..c5fcbc3e39 --- /dev/null +++ b/docs/releases/1.4.4.txt @@ -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. diff --git a/docs/releases/1.4.5.txt b/docs/releases/1.4.5.txt new file mode 100644 index 0000000000..9ba5235f79 --- /dev/null +++ b/docs/releases/1.4.5.txt @@ -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 +`. + +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``. diff --git a/docs/releases/index.txt b/docs/releases/index.txt index 85b3d211a8..4bd6ffb558 100644 --- a/docs/releases/index.txt +++ b/docs/releases/index.txt @@ -37,6 +37,9 @@ Final releases .. toctree:: :maxdepth: 1 + 1.4.5 + 1.4.4 + 1.4.3 1.4.2 1.4.1 1.4 @@ -46,6 +49,11 @@ Final releases .. toctree:: :maxdepth: 1 + 1.3.7 + 1.3.6 + 1.3.5 + 1.3.4 + 1.3.3 1.3.2 1.3.1 1.3