[1.6.x] Added information on resolved security issues to release notes.

Backport of c07f3e60c2 from master

docs/releases/1.4.11.txt

@@ -2,7 +2,109 @@
 Django 1.4.11 release notes
 ===========================
 
-*Under development*
+*April 21, 2014*
 
-Django's vendored version of six, :mod:`django.utils.six`, has been upgraded to
+Django 1.4.11 fixes three security issues in 1.4.10. Additionally,
-the latest release (1.6.1).
+Django's vendored version of six, :mod:`django.utils.six`, has been
+upgraded to the latest release (1.6.1).
+
+Unexpected code execution using ``reverse()``
+=============================================
+
+Django's URL handling is based on a mapping of regex patterns
+(representing the URLs) to callable views, and Django's own processing
+consists of matching a requested URL against those patterns to
+determine the appropriate view to invoke.
+
+Django also provides a convenience function --
+:func:`~django.core.urlresolvers.reverse` -- which performs this process
+in the opposite direction. The ``reverse()`` function takes
+information about a view and returns a URL which would invoke that
+view. Use of ``reverse()`` is encouraged for application developers,
+as the output of ``reverse()`` is always based on the current URL
+patterns, meaning developers do not need to change other code when
+making changes to URLs.
+
+One argument signature for ``reverse()`` is to pass a dotted Python
+path to the desired view. In this situation, Django will import the
+module indicated by that dotted path as part of generating the
+resulting URL. If such a module has import-time side effects, those
+side effects will occur.
+
+Thus it is possible for an attacker to cause unexpected code
+execution, given the following conditions:
+
+1. One or more views are present which construct a URL based on user
+   input (commonly, a "next" parameter in a querystring indicating
+   where to redirect upon successful completion of an action).
+
+2. One or more modules are known to an attacker to exist on the
+   server's Python import path, which perform code execution with side
+   effects on importing.
+
+To remedy this, ``reverse()`` will now only accept and import dotted
+paths based on the view-containing modules listed in the project's :doc:`URL
+pattern configuration </topics/http/urls>`, so as to ensure that only modules
+the developer intended to be imported in this fashion can or will be imported.
+
+Caching of anonymous pages could reveal CSRF token
+==================================================
+
+Django includes both a :doc:`caching framework </topics/cache>` and a system
+for :doc:`preventing cross-site request forgery (CSRF) attacks
+</ref/contrib/csrf/>`. The CSRF-protection system is based on a random nonce
+sent to the client in a cookie which must be sent by the client on future
+requests and, in forms, a hidden value which must be submitted back with the
+form.
+
+The caching framework includes an option to cache responses to
+anonymous (i.e., unauthenticated) clients.
+
+When the first anonymous request to a given page is by a client which
+did not have a CSRF cookie, the cache framework will also cache the
+CSRF cookie and serve the same nonce to other anonymous clients who
+do not have a CSRF cookie. This can allow an attacker to obtain a
+valid CSRF cookie value and perform attacks which bypass the check for
+the cookie.
+
+To remedy this, the caching framework will no longer cache such
+responses. The heuristic for this will be:
+
+1. If the incoming request did not submit any cookies, and
+
+2. If the response did send one or more cookies, and
+
+3. If the ``Vary: Cookie`` header is set on the response, then the
+   response will not be cached.
+
+MySQL typecasting
+=================
+
+The MySQL database is known to "typecast" on certain queries; for
+example, when querying a table which contains string values, but using
+a query which filters based on an integer value, MySQL will first
+silently coerce the strings to integers and return a result based on that.
+
+If a query is performed without first converting values to the
+appropriate type, this can produce unexpected results, similar to what
+would occur if the query itself had been manipulated.
+
+Django's model field classes are aware of their own types and most
+such classes perform explicit conversion of query arguments to the
+correct database-level type before querying. However, three model
+field classes did not correctly convert their arguments:
+
+* :class:`~django.db.models.FilePathField`
+* :class:`~django.db.models.GenericIPAddressField`
+* :class:`~django.db.models.IPAddressField`
+
+These three fields have been updated to convert their arguments to the
+correct types before querying.
+
+Additionally, developers of custom model fields are now warned via
+documentation to ensure their custom field classes will perform
+appropriate type conversions, and users of the :meth:`raw()
+<django.db.models.query.QuerySet.raw>` and :meth:`extra()
+<django.db.models.query.QuerySet.extra>` query methods -- which allow the
+developer to supply raw SQL or SQL fragments -- will be advised to ensure they
+perform appropriate manual type conversions prior to executing queries.

docs/releases/1.5.6.txt

@@ -2,10 +2,111 @@
 Django 1.5.6 release notes
 ==========================
 
-*Under development*
+*April 21, 2014*
 
-Django's vendored version of six, :mod:`django.utils.six`, has been upgraded to
+Django 1.5.6 fixes several bugs in 1.5.5, including three security
-the latest release (1.6.1).
+issues.
+
+Unexpected code execution using ``reverse()``
+=============================================
+
+Django's URL handling is based on a mapping of regex patterns
+(representing the URLs) to callable views, and Django's own processing
+consists of matching a requested URL against those patterns to
+determine the appropriate view to invoke.
+
+Django also provides a convenience function --
+:func:`~django.core.urlresolvers.reverse` -- which performs this process
+in the opposite direction. The ``reverse()`` function takes
+information about a view and returns a URL which would invoke that
+view. Use of ``reverse()`` is encouraged for application developers,
+as the output of ``reverse()`` is always based on the current URL
+patterns, meaning developers do not need to change other code when
+making changes to URLs.
+
+One argument signature for ``reverse()`` is to pass a dotted Python
+path to the desired view. In this situation, Django will import the
+module indicated by that dotted path as part of generating the
+resulting URL. If such a module has import-time side effects, those
+side effects will occur.
+
+Thus it is possible for an attacker to cause unexpected code
+execution, given the following conditions:
+
+1. One or more views are present which construct a URL based on user
+   input (commonly, a "next" parameter in a querystring indicating
+   where to redirect upon successful completion of an action).
+
+2. One or more modules are known to an attacker to exist on the
+   server's Python import path, which perform code execution with side
+   effects on importing.
+
+To remedy this, ``reverse()`` will now only accept and import dotted
+paths based on the view-containing modules listed in the project's :doc:`URL
+pattern configuration </topics/http/urls>`, so as to ensure that only modules
+the developer intended to be imported in this fashion can or will be imported.
+
+Caching of anonymous pages could reveal CSRF token
+==================================================
+
+Django includes both a :doc:`caching framework </topics/cache>` and a system
+for :doc:`preventing cross-site request forgery (CSRF) attacks
+</ref/contrib/csrf/>`. The CSRF-protection system is based on a random nonce
+sent to the client in a cookie which must be sent by the client on future
+requests and, in forms, a hidden value which must be submitted back with the
+form.
+
+The caching framework includes an option to cache responses to
+anonymous (i.e., unauthenticated) clients.
+
+When the first anonymous request to a given page is by a client which
+did not have a CSRF cookie, the cache framework will also cache the
+CSRF cookie and serve the same nonce to other anonymous clients who
+do not have a CSRF cookie. This can allow an attacker to obtain a
+valid CSRF cookie value and perform attacks which bypass the check for
+the cookie.
+
+To remedy this, the caching framework will no longer cache such
+responses. The heuristic for this will be:
+
+1. If the incoming request did not submit any cookies, and
+
+2. If the response did send one or more cookies, and
+
+3. If the ``Vary: Cookie`` header is set on the response, then the
+   response will not be cached.
+
+MySQL typecasting
+=================
+
+The MySQL database is known to "typecast" on certain queries; for
+example, when querying a table which contains string values, but using
+a query which filters based on an integer value, MySQL will first
+silently coerce the strings to integers and return a result based on that.
+
+If a query is performed without first converting values to the
+appropriate type, this can produce unexpected results, similar to what
+would occur if the query itself had been manipulated.
+
+Django's model field classes are aware of their own types and most
+such classes perform explicit conversion of query arguments to the
+correct database-level type before querying. However, three model
+field classes did not correctly convert their arguments:
+
+* :class:`~django.db.models.FilePathField`
+* :class:`~django.db.models.GenericIPAddressField`
+* :class:`~django.db.models.IPAddressField`
+
+These three fields have been updated to convert their arguments to the
+correct types before querying.
+
+Additionally, developers of custom model fields are now warned via
+documentation to ensure their custom field classes will perform
+appropriate type conversions, and users of the :meth:`raw()
+<django.db.models.query.QuerySet.raw>` and :meth:`extra()
+<django.db.models.query.QuerySet.extra>` query methods -- which allow the
+developer to supply raw SQL or SQL fragments -- will be advised to ensure they
+perform appropriate manual type conversions prior to executing queries.
 
 Bugfixes
 ========
@@ -13,3 +114,6 @@ Bugfixes
 * Fixed :class:`~django.contrib.auth.backends.ModelBackend` raising
   ``UnboundLocalError`` if :func:`~django.contrib.auth.get_user_model`
   raised an error (#21439).
+
+Additionally, Django's vendored version of six, :mod:`django.utils.six`,
+has been upgraded to the latest release (1.6.1).

docs/releases/1.6.3.txt

@@ -2,10 +2,111 @@
 Django 1.6.3 release notes
 ==========================
 
-*Under development*
+*April 21, 2014*
 
-This is Django 1.6.3, a bugfix release for Django 1.6. Django 1.6.3 fixes
+Django 1.6.3 fixes several bugs in 1.6.2, including three security issues,
-several bugs in 1.6.2 and makes one backwards-incompatible change:
+and makes one backwards-incompatible change:
+
+Unexpected code execution using ``reverse()``
+=============================================
+
+Django's URL handling is based on a mapping of regex patterns
+(representing the URLs) to callable views, and Django's own processing
+consists of matching a requested URL against those patterns to
+determine the appropriate view to invoke.
+
+Django also provides a convenience function --
+:func:`~django.core.urlresolvers.reverse` -- which performs this process
+in the opposite direction. The ``reverse()`` function takes
+information about a view and returns a URL which would invoke that
+view. Use of ``reverse()`` is encouraged for application developers,
+as the output of ``reverse()`` is always based on the current URL
+patterns, meaning developers do not need to change other code when
+making changes to URLs.
+
+One argument signature for ``reverse()`` is to pass a dotted Python
+path to the desired view. In this situation, Django will import the
+module indicated by that dotted path as part of generating the
+resulting URL. If such a module has import-time side effects, those
+side effects will occur.
+
+Thus it is possible for an attacker to cause unexpected code
+execution, given the following conditions:
+
+1. One or more views are present which construct a URL based on user
+   input (commonly, a "next" parameter in a querystring indicating
+   where to redirect upon successful completion of an action).
+
+2. One or more modules are known to an attacker to exist on the
+   server's Python import path, which perform code execution with side
+   effects on importing.
+
+To remedy this, ``reverse()`` will now only accept and import dotted
+paths based on the view-containing modules listed in the project's :doc:`URL
+pattern configuration </topics/http/urls>`, so as to ensure that only modules
+the developer intended to be imported in this fashion can or will be imported.
+
+Caching of anonymous pages could reveal CSRF token
+==================================================
+
+Django includes both a :doc:`caching framework </topics/cache>` and a system
+for :doc:`preventing cross-site request forgery (CSRF) attacks
+</ref/contrib/csrf/>`. The CSRF-protection system is based on a random nonce
+sent to the client in a cookie which must be sent by the client on future
+requests and, in forms, a hidden value which must be submitted back with the
+form.
+
+The caching framework includes an option to cache responses to
+anonymous (i.e., unauthenticated) clients.
+
+When the first anonymous request to a given page is by a client which
+did not have a CSRF cookie, the cache framework will also cache the
+CSRF cookie and serve the same nonce to other anonymous clients who
+do not have a CSRF cookie. This can allow an attacker to obtain a
+valid CSRF cookie value and perform attacks which bypass the check for
+the cookie.
+
+To remedy this, the caching framework will no longer cache such
+responses. The heuristic for this will be:
+
+1. If the incoming request did not submit any cookies, and
+
+2. If the response did send one or more cookies, and
+
+3. If the ``Vary: Cookie`` header is set on the response, then the
+   response will not be cached.
+
+MySQL typecasting
+=================
+
+The MySQL database is known to "typecast" on certain queries; for
+example, when querying a table which contains string values, but using
+a query which filters based on an integer value, MySQL will first
+silently coerce the strings to integers and return a result based on that.
+
+If a query is performed without first converting values to the
+appropriate type, this can produce unexpected results, similar to what
+would occur if the query itself had been manipulated.
+
+Django's model field classes are aware of their own types and most
+such classes perform explicit conversion of query arguments to the
+correct database-level type before querying. However, three model
+field classes did not correctly convert their arguments:
+
+* :class:`~django.db.models.FilePathField`
+* :class:`~django.db.models.GenericIPAddressField`
+* :class:`~django.db.models.IPAddressField`
+
+These three fields have been updated to convert their arguments to the
+correct types before querying.
+
+Additionally, developers of custom model fields are now warned via
+documentation to ensure their custom field classes will perform
+appropriate type conversions, and users of the :meth:`raw()
+<django.db.models.query.QuerySet.raw>` and :meth:`extra()
+<django.db.models.query.QuerySet.extra>` query methods -- which allow the
+developer to supply raw SQL or SQL fragments -- will be advised to ensure they
+perform appropriate manual type conversions prior to executing queries.
 
 ``select_for_update()`` requires a transaction
 ==============================================