From f0dc8e66ca6802197f1c513263c4026b228a84e6 Mon Sep 17 00:00:00 2001 From: Mariusz Felisiak Date: Thu, 1 Jul 2021 08:40:02 +0200 Subject: [PATCH 01/12] [3.1.x] Post-release version bump. --- django/__init__.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/django/__init__.py b/django/__init__.py index c4b31bd522f6..5aeca281adb7 100644 --- a/django/__init__.py +++ b/django/__init__.py @@ -1,6 +1,6 @@ from django.utils.version import get_version -VERSION = (3, 1, 13, 'final', 0) +VERSION = (3, 1, 14, 'alpha', 0) __version__ = get_version(VERSION) From 2efb39deb8d001dc8e84d1f4097c23812f83945c Mon Sep 17 00:00:00 2001 From: Mariusz Felisiak Date: Thu, 1 Jul 2021 09:57:08 +0200 Subject: [PATCH 02/12] [3.1.x] Added CVE-2021-35042 to security archive. Backport of 8feb2a49fa37528823cc900bbd9609319738193e from main --- docs/releases/security.txt | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/docs/releases/security.txt b/docs/releases/security.txt index 4d9096856297..55f91b28e1a1 100644 --- a/docs/releases/security.txt +++ b/docs/releases/security.txt @@ -1230,3 +1230,16 @@ Versions affected * Django 3.2 :commit:`(patch) <9f75e2e562fa0c0482f3dde6fc7399a9070b4a3d>` * Django 3.1 :commit:`(patch) <203d4ab9ebcd72fc4d6eb7398e66ed9e474e118e>` * Django 2.2 :commit:`(patch) ` + +July 1, 2021 - :cve:`2021-35042` +-------------------------------- + +Potential SQL injection via unsanitized ``QuerySet.order_by()`` input. `Full +description +`__ + +Versions affected +~~~~~~~~~~~~~~~~~ + +* Django 3.2 :commit:`(patch) ` +* Django 3.1 :commit:`(patch) <0bd57a879a0d54920bb9038a732645fb917040e9>` From cb149dd1946c4ec5f15a8edd4df062d1c0a5e93a Mon Sep 17 00:00:00 2001 From: Mariusz Felisiak Date: Tue, 13 Jul 2021 20:21:22 +0200 Subject: [PATCH 03/12] [3.1.x] Refs #31676 -- Removed Django Core-Mentorship mailing list references in docs. Backport of 37e8367c359cd115f109d82f99ff32be219f4928 from main --- docs/conf.py | 1 - docs/internals/mailing-lists.txt | 17 ----------------- docs/internals/organization.txt | 4 +--- 3 files changed, 1 insertion(+), 21 deletions(-) diff --git a/docs/conf.py b/docs/conf.py index d3c09110da52..b47e2972758b 100644 --- a/docs/conf.py +++ b/docs/conf.py @@ -241,7 +241,6 @@ def django_release(): # Appended to every page rst_epilog = """ .. |django-users| replace:: :ref:`django-users ` -.. |django-core-mentorship| replace:: :ref:`django-core-mentorship ` .. |django-developers| replace:: :ref:`django-developers ` .. |django-announce| replace:: :ref:`django-announce ` .. |django-updates| replace:: :ref:`django-updates ` diff --git a/docs/internals/mailing-lists.txt b/docs/internals/mailing-lists.txt index d5b9ab5f9ced..cdf5b6d26451 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 b2d399255f66..9260077cb18a 100644 --- a/docs/internals/organization.txt +++ b/docs/internals/organization.txt @@ -112,9 +112,7 @@ 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 `. +when they're ready. 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, From cd391be832ca4ea4a58824ab2d498b752b111b1b Mon Sep 17 00:00:00 2001 From: Jacob Walls Date: Fri, 16 Jul 2021 14:30:21 -0400 Subject: [PATCH 04/12] [3.1.x] Fixed typo in docs/releases/3.1.13.txt. Backport of 00c724f2f255bd3c28a73cc51db8a052644ff949 from main --- docs/releases/3.1.13.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/releases/3.1.13.txt b/docs/releases/3.1.13.txt index af8ccec5357b..b4cc930ec668 100644 --- a/docs/releases/3.1.13.txt +++ b/docs/releases/3.1.13.txt @@ -4,7 +4,7 @@ Django 3.1.13 release notes *July 1, 2021* -Django 3.1.13 fixes a security issues with severity "high" in 3.1.12. +Django 3.1.13 fixes a security issue with severity "high" in 3.1.12. CVE-2021-35042: Potential SQL injection via unsanitized ``QuerySet.order_by()`` input ===================================================================================== From d94b1e44b2614ed30a9ed8f5bd557013ed578d19 Mon Sep 17 00:00:00 2001 From: Mariusz Felisiak Date: Tue, 20 Jul 2021 10:48:17 +0200 Subject: [PATCH 05/12] [3.1.x] Refs #31676 -- Removed Core team from organization docs. According to DEP 0010. Backport of caa2dd08c4722c8702588f5dfe1fa4c506aa66fc from main --- docs/internals/organization.txt | 101 -------------------------------- 1 file changed, 101 deletions(-) diff --git a/docs/internals/organization.txt b/docs/internals/organization.txt index 9260077cb18a..3c289454f1c1 100644 --- a/docs/internals/organization.txt +++ b/docs/internals/organization.txt @@ -21,107 +21,6 @@ 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. - -.. _core-team: - -Core team -========= - -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. - -Prerogatives ------------- - -Core team members may participate in formal votes, typically to nominate new -team members and to elect the technical board. - -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. - -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. - -Core team members who have commit access are referred to as "committers" or -"core developers". - -Other permissions, such as access to the servers, are granted to those who -need them through the same process. - -Membership ----------- - -`Django team members `_ -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. - -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. - .. _technical-board: Technical board From 34a0bb5d50506b0992c6f6208e15c8b5f1a5a0b1 Mon Sep 17 00:00:00 2001 From: Mariusz Felisiak Date: Tue, 20 Jul 2021 11:13:09 +0200 Subject: [PATCH 06/12] [3.1.x] Refs #31676 -- Added Mergers and Releasers to organization docs. According to DEP 0010. Backport of 228ec8e015bac9751c8aef3107358fbb2cb3301b from main --- docs/internals/organization.txt | 143 +++++++++++++++++++++++++++++++- 1 file changed, 142 insertions(+), 1 deletion(-) diff --git a/docs/internals/organization.txt b/docs/internals/organization.txt index 3c289454f1c1..9f6f55dbcb11 100644 --- a/docs/internals/organization.txt +++ b/docs/internals/organization.txt @@ -21,6 +21,143 @@ and its community. .. _Django Code of Conduct: https://www.djangoproject.com/conduct/ .. _Django Software Foundation: https://www.djangoproject.com/foundation/ +.. _mergers-team: + +Mergers +======= + +Role +---- + +Mergers_ are a small set of people who merge pull requests to the `Django Git +repository `_. + +Prerogatives +------------ + +Mergers hold the following prerogatives: + +- 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: + + - another Merger, + - a technical board member, + - a member of the `triage & review team`_, or + - a member of the `security team`_. + +- 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. + +.. _`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 +---------- + +`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. + +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. + +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 +---- + +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 +------------ + +Releasers_ :doc:`build Django releases ` 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. + +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. + +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. + +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: + +- Becoming disqualified due to actions taken by the Code of Conduct committee + of the Django Software Foundation. +- A vote of the technical board. + +.. _`Python Package Index`: https://pypi.org/project/Django/ +.. _djangoproject.com: https://www.djangoproject.com/download/ + .. _technical-board: Technical board @@ -78,7 +215,11 @@ board. The election process works as follows: Both the application and the voting period last between one and two weeks, at the outgoing board's discretion. -.. _the technical board: https://www.djangoproject.com/foundation/teams/#technical-board-team +.. _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 Changing the organization ========================= From febc980e89591ffdc6df86cbeac13d7dfd89876e Mon Sep 17 00:00:00 2001 From: Mariusz Felisiak Date: Wed, 21 Jul 2021 11:06:58 +0200 Subject: [PATCH 07/12] [3.1.x] Refs #31676 -- Updated technical board description in organization docs. According to DEP 0010. Backport of f2ed2211c26ba375390cb76725c95ae970a0fd1d from main. --- docs/internals/organization.txt | 158 +++++++++++++++++++++++--------- 1 file changed, 115 insertions(+), 43 deletions(-) diff --git a/docs/internals/organization.txt b/docs/internals/organization.txt index 9f6f55dbcb11..b124b4b5fe93 100644 --- a/docs/internals/organization.txt +++ b/docs/internals/organization.txt @@ -30,7 +30,7 @@ Role ---- Mergers_ are a small set of people who merge pull requests to the `Django Git -repository `_. +repository`_. Prerogatives ------------ @@ -166,63 +166,135 @@ Technical board 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. +The technical board is a group of experienced contributors who: -Prerogatives ------------- - -The technical board holds two prerogatives: - -- 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. +- 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. -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. +Their main concern is to maintain the quality and stability of the Django Web +Framework. -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. +Prerogatives +------------ -In addition, at its discretion, the technical board may act in an advisory -capacity on non-technical decisions. +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 committers. They're expected -to be experienced but there's no formal seniority requirement. - -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: - -#. Candidates advertise their application for the technical board to the team. - - They must be committers already. There's no term limit for technical board - members. - -#. Each team member can vote for zero to five people among the candidates. - Candidates are ranked by the total number of votes they received. - - In case of a tie, the person who joined the core team earlier wins. - -Both the application and the voting period last between one and two weeks, at -the outgoing board's discretion. +`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 From 9dd1f9572fa5024deb1615266a0cd9995b27bd41 Mon Sep 17 00:00:00 2001 From: Mariusz Felisiak Date: Thu, 2 Sep 2021 10:56:56 +0200 Subject: [PATCH 08/12] [3.1.x] Fixed #33082 -- Fixed CommandTests.test_subparser_invalid_option on Python 3.9.7+. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Thanks Michał Górny for the report. Backport of 50ed545e2fa02c51e0d1559b83624f256e4b499b from main. --- tests/user_commands/tests.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/user_commands/tests.py b/tests/user_commands/tests.py index 0a3b6ae77ebf..ff600d986ee3 100644 --- a/tests/user_commands/tests.py +++ b/tests/user_commands/tests.py @@ -241,7 +241,7 @@ def test_subparser_dest_required_args(self): 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) if PY37: From 61c2d58d017874283921537f8ff1fe31b7652a63 Mon Sep 17 00:00:00 2001 From: Mariusz Felisiak Date: Tue, 12 Oct 2021 15:16:00 +0200 Subject: [PATCH 09/12] [3.1.x] Added 'formatter' to spelling wordlist. Backport of e43a131887e2a316d4fb829c3a272ef0cbbeea80 from main --- docs/spelling_wordlist | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/spelling_wordlist b/docs/spelling_wordlist index 856680371510..8942117543da 100644 --- a/docs/spelling_wordlist +++ b/docs/spelling_wordlist @@ -222,6 +222,7 @@ flatpages Flatpages followup fooapp +formatter formatters formfield formset From cfb780dafe29e2243d9b48d0783b729b315341bb Mon Sep 17 00:00:00 2001 From: Mariusz Felisiak Date: Mon, 29 Nov 2021 13:21:54 +0100 Subject: [PATCH 10/12] [3.1.x] Added stub release notes 3.1.14 and 2.2.25. Backport of ae4077e13ea2e4c460c3f21b9aab93a696590851 from main. --- docs/releases/2.2.25.txt | 9 +++++++++ docs/releases/3.1.14.txt | 9 +++++++++ docs/releases/index.txt | 2 ++ 3 files changed, 20 insertions(+) create mode 100644 docs/releases/2.2.25.txt create mode 100644 docs/releases/3.1.14.txt diff --git a/docs/releases/2.2.25.txt b/docs/releases/2.2.25.txt new file mode 100644 index 000000000000..e8e552d80e64 --- /dev/null +++ b/docs/releases/2.2.25.txt @@ -0,0 +1,9 @@ +=========================== +Django 2.2.25 release notes +=========================== + +*December 7, 2021* + +Django 2.2.25 fixes a security issue with severity "low" in 2.2.24. + +... diff --git a/docs/releases/3.1.14.txt b/docs/releases/3.1.14.txt new file mode 100644 index 000000000000..45775c3ce62b --- /dev/null +++ b/docs/releases/3.1.14.txt @@ -0,0 +1,9 @@ +=========================== +Django 3.1.14 release notes +=========================== + +*December 7, 2021* + +Django 3.1.14 fixes a security issue with severity "low" in 3.1.13. + +... diff --git a/docs/releases/index.txt b/docs/releases/index.txt index e54a30f5a17b..973e43bd2cc3 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 + 3.1.14 3.1.13 3.1.12 3.1.11 @@ -66,6 +67,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 From 22bd17488159601bf0741b70ae7932bffea8eced Mon Sep 17 00:00:00 2001 From: Florian Apolloner Date: Mon, 29 Nov 2021 11:52:03 +0100 Subject: [PATCH 11/12] [3.1.x] Fixed #30530, CVE-2021-44420 -- Fixed potential bypass of an upstream access control based on URL paths. Thanks Sjoerd Job Postmus and TengMA(@te3t123) for reports. Backport of d4dcd5b9dd9e462fec8220e33e3e6c822b7e88a6 from main. --- django/urls/resolvers.py | 8 ++++++-- docs/releases/2.2.25.txt | 6 +++++- docs/releases/3.1.14.txt | 6 +++++- tests/urlpatterns/tests.py | 13 +++++++++++++ 4 files changed, 29 insertions(+), 4 deletions(-) diff --git a/django/urls/resolvers.py b/django/urls/resolvers.py index e565d34b2733..abf0a11572e8 100644 --- a/django/urls/resolvers.py +++ b/django/urls/resolvers.py @@ -153,7 +153,11 @@ def __init__(self, regex, name=None, is_endpoint=False): 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 @@ -240,7 +244,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/releases/2.2.25.txt b/docs/releases/2.2.25.txt index e8e552d80e64..1662451a3064 100644 --- a/docs/releases/2.2.25.txt +++ b/docs/releases/2.2.25.txt @@ -6,4 +6,8 @@ Django 2.2.25 release notes 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/3.1.14.txt b/docs/releases/3.1.14.txt index 45775c3ce62b..fb6fef88842d 100644 --- a/docs/releases/3.1.14.txt +++ b/docs/releases/3.1.14.txt @@ -6,4 +6,8 @@ Django 3.1.14 release notes Django 3.1.14 fixes a security issue with severity "low" in 3.1.13. -... +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/tests/urlpatterns/tests.py b/tests/urlpatterns/tests.py index 54b7e0981331..98866f0b7934 100644 --- a/tests/urlpatterns/tests.py +++ b/tests/urlpatterns/tests.py @@ -147,6 +147,19 @@ def test_space_in_route(self): with self.assertRaisesMessage(ImproperlyConfigured, msg): path('space/', 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): From 840bebf1eef1c2a373158262cdfec611dc535658 Mon Sep 17 00:00:00 2001 From: Mariusz Felisiak Date: Tue, 7 Dec 2021 06:57:40 +0100 Subject: [PATCH 12/12] [3.1.x] Bumped version for 3.1.14 release. --- django/__init__.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/django/__init__.py b/django/__init__.py index 5aeca281adb7..100b36676849 100644 --- a/django/__init__.py +++ b/django/__init__.py @@ -1,6 +1,6 @@ from django.utils.version import get_version -VERSION = (3, 1, 14, 'alpha', 0) +VERSION = (3, 1, 14, 'final', 0) __version__ = get_version(VERSION) pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy