Bug#1001285: bullseye-pu: package python-django/2:2.2.25-1~debu11u1
Hi Kibi,
>> python-django (2:2.2.25-1~debu11u1) bullseye; urgency=medium
>
> That should probably be 2:2.2.25-1~deb11u1 (first 'u') trimmed?
Oh, great spot. Here's the updated changelog entry (below) and the updated
debdiff is attached.
+python-django (2:2.2.25-1~deb11u1) bullseye; urgency=medium
+
+ * New upstream security release:
+
+ - CVE-2021-44420: Potential bypass of an upstream access control based on
+ URL paths.
+
+ Full details are available here:
+ <https://www.djangoproject.com/weblog/2021/dec/07/security-releases/>
+
+ * Update gbp.conf for bullseye release.
+
+ -- Chris Lamb <lamby@debian.org> Tue, 07 Dec 2021 09:29:21 -0800
Regards,
--
,''`.
: :' : Chris Lamb
`. `'` lamby@debian.org 🍥 chris-lamb.co.uk
`-
diff --git a/Django.egg-info/PKG-INFO b/Django.egg-info/PKG-INFO
index bfed6be0f..ecc68c78d 100644
--- a/Django.egg-info/PKG-INFO
+++ b/Django.egg-info/PKG-INFO
@@ -1,6 +1,6 @@
Metadata-Version: 2.1
Name: Django
-Version: 2.2.24
+Version: 2.2.25
Summary: A high-level Python Web framework that encourages rapid development and clean, pragmatic design.
Home-page: https://www.djangoproject.com/
Author: Django Software Foundation
@@ -76,5 +76,5 @@ Classifier: Topic :: Internet :: WWW/HTTP :: WSGI
Classifier: Topic :: Software Development :: Libraries :: Application Frameworks
Classifier: Topic :: Software Development :: Libraries :: Python Modules
Requires-Python: >=3.5
-Provides-Extra: bcrypt
Provides-Extra: argon2
+Provides-Extra: bcrypt
diff --git a/Django.egg-info/SOURCES.txt b/Django.egg-info/SOURCES.txt
index 712c72f32..7c210f1d4 100644
--- a/Django.egg-info/SOURCES.txt
+++ b/Django.egg-info/SOURCES.txt
@@ -3387,6 +3387,7 @@ docs/contents.txt
docs/glossary.txt
docs/index.txt
docs/make.bat
+docs/requirements.txt
docs/spelling_wordlist
docs/_ext/djangodocs.py
docs/_theme/djangodocs/genindex.html
@@ -3834,6 +3835,7 @@ docs/releases/2.2.21.txt
docs/releases/2.2.22.txt
docs/releases/2.2.23.txt
docs/releases/2.2.24.txt
+docs/releases/2.2.25.txt
docs/releases/2.2.3.txt
docs/releases/2.2.4.txt
docs/releases/2.2.5.txt
diff --git a/PKG-INFO b/PKG-INFO
index bfed6be0f..ecc68c78d 100644
--- a/PKG-INFO
+++ b/PKG-INFO
@@ -1,6 +1,6 @@
Metadata-Version: 2.1
Name: Django
-Version: 2.2.24
+Version: 2.2.25
Summary: A high-level Python Web framework that encourages rapid development and clean, pragmatic design.
Home-page: https://www.djangoproject.com/
Author: Django Software Foundation
@@ -76,5 +76,5 @@ Classifier: Topic :: Internet :: WWW/HTTP :: WSGI
Classifier: Topic :: Software Development :: Libraries :: Application Frameworks
Classifier: Topic :: Software Development :: Libraries :: Python Modules
Requires-Python: >=3.5
-Provides-Extra: bcrypt
Provides-Extra: argon2
+Provides-Extra: bcrypt
diff --git a/debian/changelog b/debian/changelog
index 6deb982f9..68a035164 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+python-django (2:2.2.25-1~deb11u1) bullseye; urgency=medium
+
+ * New upstream security release:
+
+ - CVE-2021-44420: Potential bypass of an upstream access control based on
+ URL paths.
+
+ Full details are available here:
+ <https://www.djangoproject.com/weblog/2021/dec/07/security-releases/>
+
+ * Update gbp.conf for bullseye release.
+
+ -- Chris Lamb <lamby@debian.org> Tue, 07 Dec 2021 09:29:21 -0800
+
python-django (2:2.2.24-1) unstable; urgency=medium
* New upstream security release. (Closes: #989394)
diff --git a/debian/gbp.conf b/debian/gbp.conf
index 114ce39f3..f97b5cfdf 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -1,6 +1,6 @@
[DEFAULT]
upstream-branch=upstream/2.0.x
-debian-branch=debian/sid
+debian-branch=debian/bullseye
pristine-tar=True
[pq]
diff --git a/django/__init__.py b/django/__init__.py
index 7963a360d..4fbd3665a 100644
--- a/django/__init__.py
+++ b/django/__init__.py
@@ -1,6 +1,6 @@
from django.utils.version import get_version
-VERSION = (2, 2, 24, 'final', 0)
+VERSION = (2, 2, 25, 'final', 0)
__version__ = get_version(VERSION)
diff --git a/django/urls/resolvers.py b/django/urls/resolvers.py
index 5b722474c..3f8f6c00e 100644
--- a/django/urls/resolvers.py
+++ b/django/urls/resolvers.py
@@ -147,7 +147,11 @@ class RegexPattern(CheckURLMixin):
self.converters = {}
def match(self, path):
- match = self.regex.search(path)
+ match = (
+ self.regex.fullmatch(path)
+ if self._is_endpoint and self.regex.pattern.endswith('$')
+ else self.regex.search(path)
+ )
if match:
# If there are any named groups, use those as kwargs, ignoring
# non-named groups. Otherwise, pass all non-named arguments as
@@ -230,7 +234,7 @@ def _route_to_regex(route, is_endpoint=False):
converters[parameter] = converter
parts.append('(?P<' + parameter + '>' + converter.regex + ')')
if is_endpoint:
- parts.append('$')
+ parts.append(r'\Z')
return ''.join(parts), converters
diff --git a/docs/_ext/djangodocs.py b/docs/_ext/djangodocs.py
index cc40c40cd..1fa3e4bf5 100644
--- a/docs/_ext/djangodocs.py
+++ b/docs/_ext/djangodocs.py
@@ -8,7 +8,7 @@ import re
from docutils import nodes
from docutils.parsers.rst import Directive
from docutils.statemachine import ViewList
-from sphinx import addnodes
+from sphinx import addnodes, version_info as sphinx_version
from sphinx.builders.html import StandaloneHTMLBuilder
from sphinx.directives.code import CodeBlock
from sphinx.domains.std import Cmdoption
@@ -114,11 +114,17 @@ class DjangoHTMLTranslator(HTMLTranslator):
def visit_table(self, node):
self.context.append(self.compact_p)
self.compact_p = True
- self._table_row_index = 0 # Needed by Sphinx
+ # Needed by Sphinx.
+ if sphinx_version >= (4, 3):
+ self._table_row_indices.append(0)
+ else:
+ self._table_row_index = 0
self.body.append(self.starttag(node, 'table', CLASS='docutils'))
def depart_table(self, node):
self.compact_p = self.context.pop()
+ if sphinx_version >= (4, 3):
+ self._table_row_indices.pop()
self.body.append('</table>\n')
def visit_desc_parameterlist(self, node):
diff --git a/docs/conf.py b/docs/conf.py
index 9526cc411..52fa18fc1 100644
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -118,7 +118,7 @@ today_fmt = '%B %d, %Y'
# List of patterns, relative to source directory, that match files and
# directories to ignore when looking for source files.
-exclude_patterns = ['_build', '_theme']
+exclude_patterns = ['_build', '_theme', 'requirements.txt']
# The reST default role (used for this markup: `text`) to use for all documents.
# default_role = None
@@ -234,7 +234,6 @@ modindex_common_prefix = ["django."]
# Appended to every page
rst_epilog = """
.. |django-users| replace:: :ref:`django-users <django-users-mailing-list>`
-.. |django-core-mentorship| replace:: :ref:`django-core-mentorship <django-core-mentorship-mailing-list>`
.. |django-developers| replace:: :ref:`django-developers <django-developers-mailing-list>`
.. |django-announce| replace:: :ref:`django-announce <django-announce-mailing-list>`
.. |django-updates| replace:: :ref:`django-updates <django-updates-mailing-list>`
diff --git a/docs/internals/mailing-lists.txt b/docs/internals/mailing-lists.txt
index d5b9ab5f9..cdf5b6d26 100644
--- a/docs/internals/mailing-lists.txt
+++ b/docs/internals/mailing-lists.txt
@@ -35,23 +35,6 @@ installation, usage, or debugging of Django.
.. _django-users subscription email address: mailto:django-users+subscribe@googlegroups.com
.. _django-users posting email: mailto:django-users@googlegroups.com
-.. _django-core-mentorship-mailing-list:
-
-``django-core-mentorship``
-==========================
-
-The Django Core Mentorship list is intended to provide a welcoming
-introductory environment for community members interested in contributing to
-the Django Project.
-
-* `django-core-mentorship mailing archive`_
-* `django-core-mentorship subscription email address`_
-* `django-core-mentorship posting email`_
-
-.. _django-core-mentorship mailing archive: https://groups.google.com/d/forum/django-core-mentorship
-.. _django-core-mentorship subscription email address: mailto:django-core-mentorship+subscribe@googlegroups.com
-.. _django-core-mentorship posting email: mailto:django-core-mentorship@googlegroups.com
-
.. _django-developers-mailing-list:
``django-developers``
diff --git a/docs/internals/organization.txt b/docs/internals/organization.txt
index b2d399255..b124b4b5f 100644
--- a/docs/internals/organization.txt
+++ b/docs/internals/organization.txt
@@ -21,170 +21,280 @@ and its community.
.. _Django Code of Conduct: https://www.djangoproject.com/conduct/
.. _Django Software Foundation: https://www.djangoproject.com/foundation/
-The Django core team makes the decisions, nominates its new members, and
-elects its technical board. While it holds decision power in theory, it aims
-at using it as rarely as possible in practice. Rough consensus should be the
-norm and formal voting an exception.
+.. _mergers-team:
-.. _core-team:
-
-Core team
-=========
+Mergers
+=======
Role
----
-The core team is the group of trusted volunteers who manage the Django
-Project. They assume many roles required to achieve the project's goals,
-especially those that require a high level of trust. They make the decisions
-that shape the future of the project.
-
-Core team members are expected to act as role models for the community and
-custodians of the project, on behalf of the community and all those who rely
-on Django.
-
-They will intervene, where necessary, in online discussions or at official
-Django events on the rare occasions that a situation arises that requires
-intervention.
-
-They have authority over the Django Project infrastructure, including the
-Django Project website itself, the Django GitHub organization and
-repositories, the Trac bug tracker, the mailing lists, IRC channels, etc.
+Mergers_ are a small set of people who merge pull requests to the `Django Git
+repository`_.
Prerogatives
------------
-Core team members may participate in formal votes, typically to nominate new
-team members and to elect the technical board.
+Mergers hold the following prerogatives:
-Some contributions don't require commit access. Depending on the reasons why a
-contributor joins the team, they may or may not have commit permissions to the
-Django code repository.
+- Merging any pull request which constitutes a `minor change`_ (small enough
+ not to require the use of the `DEP process`_). A Merger must not merge a
+ change primarily authored by that Merger, unless the pull request has been
+ approved by:
-However, should the need arise, any team member may ask for commit access by
-writing to the core team's mailing list. Access will be granted unless the
-person withdraws their request or the technical board vetoes the proposal.
+ - another Merger,
+ - a technical board member,
+ - a member of the `triage & review team`_, or
+ - a member of the `security team`_.
-Core team members who have commit access are referred to as "committers" or
-"core developers".
+- Initiating discussion of a minor change in the appropriate venue, and request
+ that other Mergers refrain from merging it while discussion proceeds.
+- Requesting a vote of the technical board regarding any minor change if, in
+ the Merger's opinion, discussion has failed to reach a consensus.
+- Requesting a vote of the technical board when a `major change`_ (significant
+ enough to require the use of the `DEP process`_) reaches one of its
+ implementation milestones and is intended to merge.
-Other permissions, such as access to the servers, are granted to those who
-need them through the same process.
+.. _`minor change`: https://github.com/django/deps/blob/main/accepted/0010-new-governance.rst#terminology
+.. _`major change`: https://github.com/django/deps/blob/main/accepted/0010-new-governance.rst#terminology
Membership
----------
-`Django team members <https://www.djangoproject.com/foundation/teams/>`_
-demonstrate:
-
-- a good grasp of the philosophy of the Django Project
-- a solid track record of being constructive and helpful
-- significant contributions to the project's goals, in any form
-- willingness to dedicate some time to improving Django
-
-As the project matures, contributions go way beyond code. Here's an incomplete
-list of areas where contributions may be considered for joining the core team,
-in no particular order:
-
-- Working on community management and outreach
-- Providing support on the mailing-lists and on IRC
-- Triaging tickets
-- Writing patches (code, docs, or tests)
-- Reviewing patches (code, docs, or tests)
-- Participating in design decisions
-- Providing expertise in a particular domain (security, i18n, etc.)
-- Managing the continuous integration infrastructure
-- Managing the servers (website, tracker, documentation, etc.)
-- Maintaining related projects (djangoproject.com site, ex-contrib apps, etc.)
-- Creating visual designs
-
-Very few areas are reserved to core team members:
-
-- Reviewing security reports
-- Merging patches (code, docs, or tests)
-- Packaging releases
-
-Core team membership acknowledges sustained and valuable efforts that align
-well with the philosophy and the goals of the Django Project.
-
-It is granted by a four fifths majority of votes cast in a core team vote and
-no veto by the technical board.
-
-Core team members are always looking for promising contributors, teaching them
-how the project is managed, and submitting their names to the core team's vote
-when they're ready. If you would like to join the core team, you can contact a
-core team member privately or ask for guidance on the :ref:`Django Core
-Mentorship mailing-list <django-core-mentorship-mailing-list>`.
-
-There's no time limit on core team membership. However, in order to provide
-the general public with a reasonable idea of how many people maintain Django,
-core team members who have stopped contributing are encouraged to declare
-themselves as "past team members". Those who haven't made any non-trivial
-contribution in two years may be asked to move themselves to this category,
-and moved there if they don't respond. Past team members lose their privileges
-such as voting rights and commit access.
+`The technical board`_ selects Mergers_ as necessary to maintain their number
+at a minimum of three, in order to spread the workload and avoid over-burdening
+or burning out any individual Merger. There is no upper limit to the number of
+Mergers.
-.. _technical-board:
+It's not a requirement that a Merger is also a Django Fellow, but the Django
+Software Foundation has the power to use funding of Fellow positions as a way
+to make the role of Merger sustainable.
-Technical board
-===============
+The following restrictions apply to the role of Merger:
+
+- A person must not simultaneously serve as a member of the technical board. If
+ a Merger is elected to the technical board, they shall cease to be a Merger
+ immediately upon taking up membership in the technical board.
+- A person may serve in the roles of Releaser and Merger simultaneously.
+
+The selection process, when a vacancy occurs or when the technical board deems
+it necessary to select additional persons for such a role, occur as follows:
+
+- Any member in good standing of an appropriate discussion venue, or the Django
+ Software Foundation board acting with the input of the DSF's Fellowship
+ committee, may suggest a person for consideration.
+- The technical board considers the suggestions put forth, and then any member
+ of the technical board formally nominates a candidate for the role.
+- The technical board votes on nominees.
+
+Mergers may resign their role at any time, but should endeavor to provide some
+advance notice in order to allow the selection of a replacement. Termination of
+the contract of a Django Fellow by the Django Software Foundation temporarily
+suspends that person's Merger role until such time as the technical board can
+vote on their nomination.
+
+Otherwise, a Merger may be removed by:
+
+- Becoming disqualified due to election to the technical board.
+- Becoming disqualified due to actions taken by the Code of Conduct committee
+ of the Django Software Foundation.
+- A vote of the technical board.
+
+.. _releasers-team:
+
+Releasers
+=========
Role
----
-The technical board is a group of experienced and active committers who steer
-technical choices. Their main concern is to maintain the quality and stability
-of the Django Web Framework.
+Releasers_ are a small set of people who have the authority to upload packaged
+releases of Django to the `Python Package Index`_, and to the
+`djangoproject.com`_ website.
Prerogatives
------------
-The technical board holds two prerogatives:
+Releasers_ :doc:`build Django releases </internals/howto-release-django>` and
+upload them to the `Python Package Index`_, and to the `djangoproject.com`_
+website.
+
+Membership
+----------
+
+`The technical board`_ selects Releasers_ as necessary to maintain their number
+at a minimum of three, in order to spread the workload and avoid over-burdening
+or burning out any individual Releaser. There is no upper limit to the number
+of Releasers.
-- Making major technical decisions when no consensus is found otherwise. This
- happens on the |django-developers| mailing-list.
-- Veto a grant of commit access or remove commit access. This happens on the
- ``django-core`` mailing-list.
+It's not a requirement that a Releaser is also a Django Fellow, but the Django
+Software Foundation has the power to use funding of Fellow positions as a way
+to make the role of Releaser sustainable.
-In both cases, the technical board is a last resort. In these matters, it
-fulfills a similar function to the former Benevolent Dictators For Life.
+A person may serve in the roles of Releaser and Merger simultaneously.
-When the board wants to exercise one of these prerogatives, it must hold a
-private, simple majority vote on the resolution. The quorum is the full
-committee â?? each member must cast a vote or abstain explicitly. Then the board
-communicates the result, and if possible the reasons, on the appropriate
-mailing-list. There's no appeal for such decisions.
+The selection process, when a vacancy occurs or when the technical board deems
+it necessary to select additional persons for such a role, occur as follows:
-In addition, at its discretion, the technical board may act in an advisory
-capacity on non-technical decisions.
+- Any member in good standing of an appropriate discussion venue, or the Django
+ Software Foundation board acting with the input of the DSF's Fellowship
+ committee, may suggest a person for consideration.
+- The technical board considers the suggestions put forth, and then any member
+ of the technical board formally nominates a candidate for the role.
+- The technical board votes on nominees.
-Membership
-----------
+Releasers may resign their role at any time, but should endeavor to provide
+some advance notice in order to allow the selection of a replacement.
+Termination of the contract of a Django Fellow by the Django Software
+Foundation temporarily suspends that person's Releaser role until such time as
+the technical board can vote on their nomination.
+
+Otherwise, a Releaser may be removed by:
-`The technical board`_ is an elected group of five committers. They're expected
-to be experienced but there's no formal seniority requirement.
+- Becoming disqualified due to actions taken by the Code of Conduct committee
+ of the Django Software Foundation.
+- A vote of the technical board.
-A new board is elected after each feature release of Django. The election
-process is managed by a returns officer nominated by the outgoing technical
-board. The election process works as follows:
+.. _`Python Package Index`: https://pypi.org/project/Django/
+.. _djangoproject.com: https://www.djangoproject.com/download/
-#. Candidates advertise their application for the technical board to the team.
+.. _technical-board:
- They must be committers already. There's no term limit for technical board
- members.
+Technical board
+===============
-#. Each team member can vote for zero to five people among the candidates.
- Candidates are ranked by the total number of votes they received.
+Role
+----
- In case of a tie, the person who joined the core team earlier wins.
+The technical board is a group of experienced contributors who:
-Both the application and the voting period last between one and two weeks, at
-the outgoing board's discretion.
+- provide oversight of Django's development and release process,
+- assist in setting the direction of feature development and releases,
+- take part in filling certain roles, and
+- have a tie-breaking vote when other decision-making processes fail.
-.. _the technical board: https://www.djangoproject.com/foundation/teams/#technical-board-team
+Their main concern is to maintain the quality and stability of the Django Web
+Framework.
+
+Prerogatives
+------------
+
+The technical board holds the following prerogatives:
+
+- Making a binding decision regarding any question of a technical change to
+ Django.
+- Vetoing the merging of any particular piece of code into Django or ordering
+ the reversion of any particular merge or commit.
+- Announcing calls for proposals and ideas for the future technical direction
+ of Django.
+- Setting and adjusting the schedule of releases of Django.
+- Selecting and removing mergers and releasers.
+- Participating in the removal of members of the technical board, when deemed
+ appropriate.
+- Calling elections of the technical board outside of those which are
+ automatically triggered, at times when the technical board deems an election
+ is appropriate.
+- Participating in modifying Django's governance (see
+ :ref:`organization-change`).
+- Declining to vote on a matter the technical board feels is unripe for a
+ binding decision, or which the technical board feels is outside the scope of
+ its powers.
+- Taking charge of the governance of other technical teams within the Django
+ open-source project, and governing those teams accordingly.
+
+Membership
+----------
+
+`The technical board`_ is an elected group of five experienced contributors
+who demonstrate:
+
+- A history of technical contributions to Django or the Django ecosystem. This
+ history must begin at least 18 months prior to the individual's candidacy for
+ the technical board.
+- A history of participation in Django's development outside of contributions
+ merged to the `Django Git repository`_. This may include, but is not
+ restricted to:
+
+ - Participation in discussions on the |django-developers| mailing list or
+ the `Django forum`_.
+ - Reviewing and offering feedback on pull requests in the Django source-code
+ repository.
+ - Assisting in triage and management of the Django bug tracker.
+
+- A history of recent engagement with the direction and development of Django.
+ Such engagement must have occurred within a period of no more than two years
+ prior to the individual's candidacy for the technical board.
+
+A new board is elected after each release cycle of Django. The election process
+works as follows:
+
+#. The technical board direct one of its members to notify the Secretary of the
+ Django Software Foundation, in writing, of the triggering of the election,
+ and the condition which triggered it. The Secretary post to the appropriate
+ venue -- the |django-developers| mailing list and the `Django forum`_ to
+ announce the election and its timeline.
+#. As soon as the election is announced, the `DSF Board`_ begin a period of
+ voter registration. All `individual members of the DSF`_ are automatically
+ registered and need not explicitly register. All other persons who believe
+ themselves eligible to vote, but who have not yet registered to vote, may
+ make an application to the DSF Board for voting privileges. The voter
+ registration form and roll of voters is maintained by the DSF Board. The DSF
+ Board may challenge and reject the registration of voters it believes are
+ registering in bad faith or who it believes have falsified their
+ qualifications or are otherwise unqualified.
+#. Registration of voters close one week after the announcement of the
+ election. At that point, registration of candidates begin. Any qualified
+ person may register as a candidate. The candidate registration form and
+ roster of candidates are maintained by the DSF Board, and candidates must
+ provide evidence of their qualifications as part of registration. The DSF
+ Board may challenge and reject the registration of candidates it believes do
+ not meet the qualifications of members of the Technical Board, or who it
+ believes are registering in bad faith.
+#. Registration of candidates close one week after it has opened. One week
+ after registration of candidates closes, the Secretary of the DSF publish
+ the roster of candidates to the |django-developers| mailing list and the
+ `Django forum`_, and the election begin. The DSF Board provide a voting form
+ accessible to registered voters, and is the custodian of the votes.
+#. Voting is by secret ballot containing the roster of candidates, and any
+ relevant materials regarding the candidates, in a randomized order. Each
+ voter may vote for up to five candidates on the ballot.
+#. The election conclude one week after it begins. The DSF Board then tally the
+ votes and produce a summary, including the total number of votes cast and
+ the number received by each candidate. This summary is ratified by a
+ majority vote of the DSF Board, then posted by the Secretary of the DSF to
+ the |django-developers| mailing list and the Django Forum. The five
+ candidates with the highest vote totals are immediately become the new
+ technical board.
+
+A member of the technical board may be removed by:
+
+- Becoming disqualified due to actions taken by the Code of Conduct committee
+ of the Django Software Foundation.
+- Determining that they did not possess the qualifications of a member of the
+ technical board. This determination must be made jointly by the other members
+ of the technical board, and the `DSF Board`_. A valid determination of
+ ineligibility requires that all other members of the technical board and all
+ members of the DSF Board vote who can vote on the issue (the affected person,
+ if a DSF Board member, must not vote) vote "yes" on a motion that the person
+ in question is ineligible.
+
+.. _`Django forum`: https://forum.djangoproject.com/
+.. _`Django Git repository`: https://github.com/django/django/
+.. _`DSF Board`: https://www.djangoproject.com/foundation/#board
+.. _`individual members of the DSF`: https://www.djangoproject.com/foundation/individual-members/
+.. _mergers: https://www.djangoproject.com/foundation/teams/#mergers-team
+.. _releasers: https://www.djangoproject.com/foundation/teams/#releasers-team
+.. _`security team`: https://www.djangoproject.com/foundation/teams/#security-team
+.. _`the technical board`: https://www.djangoproject.com/foundation/teams/#technical-board-team
+.. _`triage & review team`: https://www.djangoproject.com/foundation/teams/#triage-review-team
+
+.. _organization-change:
Changing the organization
=========================
-Changes to this document require a four fifths majority of votes cast in a
-core team vote and no veto by the technical board.
+Changes to this document require the use of the `DEP process`_, with
+modifications described in `DEP 0010`_.
+
+.. _`DEP process`: https://github.com/django/deps/blob/main/final/0001-dep-process.rst
+.. _`DEP 0010`: https://github.com/django/deps/blob/main/accepted/0010-new-governance.rst#changing-this-governance-process
diff --git a/docs/ref/databases.txt b/docs/ref/databases.txt
index 03085eab5..dc8f6165d 100644
--- a/docs/ref/databases.txt
+++ b/docs/ref/databases.txt
@@ -102,10 +102,10 @@ below for information on how to set up your database correctly.
PostgreSQL notes
================
-Django supports PostgreSQL 9.4 and higher. `psycopg2`_ 2.5.4 or higher is
-required, though the latest release is recommended.
+Django supports PostgreSQL 9.4 and higher. `psycopg2`_ 2.5.4 through 2.8.6 is
+required, though 2.8.6 is recommended.
-.. _psycopg2: http://initd.org/psycopg/
+.. _psycopg2: https://www.psycopg.org/
PostgreSQL connection settings
-------------------------------
diff --git a/docs/releases/2.2.25.txt b/docs/releases/2.2.25.txt
new file mode 100644
index 000000000..1662451a3
--- /dev/null
+++ b/docs/releases/2.2.25.txt
@@ -0,0 +1,13 @@
+===========================
+Django 2.2.25 release notes
+===========================
+
+*December 7, 2021*
+
+Django 2.2.25 fixes a security issue with severity "low" in 2.2.24.
+
+CVE-2021-44420: Potential bypass of an upstream access control based on URL paths
+=================================================================================
+
+HTTP requests for URLs with trailing newlines could bypass an upstream access
+control based on URL paths.
diff --git a/docs/releases/index.txt b/docs/releases/index.txt
index 38bb561b9..e62548254 100644
--- a/docs/releases/index.txt
+++ b/docs/releases/index.txt
@@ -25,6 +25,7 @@ versions of the documentation contain the release notes for any later releases.
.. toctree::
:maxdepth: 1
+ 2.2.25
2.2.24
2.2.23
2.2.22
diff --git a/docs/releases/security.txt b/docs/releases/security.txt
index 509cc6ce7..4d9096856 100644
--- a/docs/releases/security.txt
+++ b/docs/releases/security.txt
@@ -1203,3 +1203,30 @@ Versions affected
* Django 3.2 :commit:`(patch) <2d2c1d0c97832860fbd6597977e2aae17dd7e5b2>`
* Django 3.1 :commit:`(patch) <afb23f5929944a407e4990edef1c7806a94c9879>`
* Django 2.2 :commit:`(patch) <d9594c4ea57b6309d93879805302cec9ae9f23ff>`
+
+June 2, 2021 - :cve:`2021-33203`
+--------------------------------
+
+Potential directory traversal via ``admindocs``. `Full description
+<https://www.djangoproject.com/weblog/2021/jun/02/security-releases/>`__
+
+Versions affected
+~~~~~~~~~~~~~~~~~
+
+* Django 3.2 :commit:`(patch) <dfaba12cda060b8b292ae1d271b44bf810b1c5b9>`
+* Django 3.1 :commit:`(patch) <20c67a0693c4ede2b09af02574823485e82e4c8f>`
+* Django 2.2 :commit:`(patch) <053cc9534d174dc89daba36724ed2dcb36755b90>`
+
+June 2, 2021 - :cve:`2021-33571`
+--------------------------------
+
+Possible indeterminate SSRF, RFI, and LFI attacks since validators accepted
+leading zeros in IPv4 addresses. `Full description
+<https://www.djangoproject.com/weblog/2021/jun/02/security-releases/>`__
+
+Versions affected
+~~~~~~~~~~~~~~~~~
+
+* Django 3.2 :commit:`(patch) <9f75e2e562fa0c0482f3dde6fc7399a9070b4a3d>`
+* Django 3.1 :commit:`(patch) <203d4ab9ebcd72fc4d6eb7398e66ed9e474e118e>`
+* Django 2.2 :commit:`(patch) <f27c38ab5d90f68c9dd60cabef248a570c0be8fc>`
diff --git a/docs/requirements.txt b/docs/requirements.txt
new file mode 100644
index 000000000..6ea137268
--- /dev/null
+++ b/docs/requirements.txt
@@ -0,0 +1,3 @@
+pyenchant
+Sphinx>=3.1.0
+sphinxcontrib-spelling
diff --git a/docs/spelling_wordlist b/docs/spelling_wordlist
index c511bdb3c..d3ab8e1c1 100644
--- a/docs/spelling_wordlist
+++ b/docs/spelling_wordlist
@@ -217,6 +217,7 @@ flatpages
Flatpages
followup
fooapp
+formatter
formatters
formfield
formset
diff --git a/tests/requirements/postgres.txt b/tests/requirements/postgres.txt
index 820d85bb4..844349958 100644
--- a/tests/requirements/postgres.txt
+++ b/tests/requirements/postgres.txt
@@ -1 +1 @@
-psycopg2-binary>=2.5.4
+psycopg2-binary>=2.5.4, < 2.9
diff --git a/tests/urlpatterns/tests.py b/tests/urlpatterns/tests.py
index f696cd531..38b4392ad 100644
--- a/tests/urlpatterns/tests.py
+++ b/tests/urlpatterns/tests.py
@@ -116,6 +116,19 @@ class SimplifiedURLTests(SimpleTestCase):
with self.assertRaisesMessage(ImproperlyConfigured, msg):
path('foo/<nonexistent:var>/', empty_view)
+ def test_path_trailing_newlines(self):
+ tests = [
+ '/articles/2003/\n',
+ '/articles/2010/\n',
+ '/en/foo/\n',
+ '/included_urls/extra/\n',
+ '/regex/1/\n',
+ '/users/1/\n',
+ ]
+ for url in tests:
+ with self.subTest(url=url), self.assertRaises(Resolver404):
+ resolve(url)
+
@override_settings(ROOT_URLCONF='urlpatterns.converter_urls')
class ConverterTests(SimpleTestCase):
diff --git a/tests/user_commands/tests.py b/tests/user_commands/tests.py
index 45fe0aaf4..f3cbf8bbf 100644
--- a/tests/user_commands/tests.py
+++ b/tests/user_commands/tests.py
@@ -218,7 +218,7 @@ class CommandTests(SimpleTestCase):
self.assertIn('bar', out.getvalue())
def test_subparser_invalid_option(self):
- msg = "Error: invalid choice: 'test' (choose from 'foo')"
+ msg = "invalid choice: 'test' (choose from 'foo')"
with self.assertRaisesMessage(CommandError, msg):
management.call_command('subparser', 'test', 12)
Reply to: