Update to 3.11.4

00399-cve-2023-24329.patch

@@ -1,229 +0,0 @@
-From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
-From: "Miss Islington (bot)"
- <31488909+miss-islington@users.noreply.github.com>
-Date: Wed, 17 May 2023 14:41:25 -0700
-Subject: [PATCH] 00399: CVE-2023-24329
-
-* gh-102153: Start stripping C0 control and space chars in `urlsplit` (GH-102508)
-
-`urllib.parse.urlsplit` has already been respecting the WHATWG spec a bit GH-25595.
-
-This adds more sanitizing to respect the "Remove any leading C0 control or space from input" [rule](https://url.spec.whatwg.org/GH-url-parsing:~:text=Remove%20any%20leading%20and%20trailing%20C0%20control%20or%20space%20from%20input.) in response to [CVE-2023-24329](https://nvd.nist.gov/vuln/detail/CVE-2023-24329).
-
----------
-
-(cherry picked from commit 2f630e1ce18ad2e07428296532a68b11dc66ad10)
-
-Co-authored-by: Illia Volochii <illia.volochii@gmail.com>
-Co-authored-by: Gregory P. Smith [Google] <greg@krypto.org>
----
- Doc/library/urllib.parse.rst                  | 46 +++++++++++++-
- Lib/test/test_urlparse.py                     | 61 ++++++++++++++++++-
- Lib/urllib/parse.py                           | 12 ++++
- ...-03-07-20-59-17.gh-issue-102153.14CLSZ.rst |  3 +
- 4 files changed, 119 insertions(+), 3 deletions(-)
- create mode 100644 Misc/NEWS.d/next/Security/2023-03-07-20-59-17.gh-issue-102153.14CLSZ.rst
-
-diff --git a/Doc/library/urllib.parse.rst b/Doc/library/urllib.parse.rst
-index 96b3965107..a326e82e30 100644
---- a/Doc/library/urllib.parse.rst
-+++ b/Doc/library/urllib.parse.rst
-@@ -159,6 +159,10 @@ or on combining URL components into a URL string.
-       ParseResult(scheme='http', netloc='www.cwi.nl:80', path='/%7Eguido/Python.html',
-                   params='', query='', fragment='')
- 
-+   .. warning::
-+
-+      :func:`urlparse` does not perform validation.  See :ref:`URL parsing
-+      security <url-parsing-security>` for details.
- 
-    .. versionchanged:: 3.2
-       Added IPv6 URL parsing capabilities.
-@@ -324,8 +328,14 @@ or on combining URL components into a URL string.
-    ``#``, ``@``, or ``:`` will raise a :exc:`ValueError`. If the URL is
-    decomposed before parsing, no error will be raised.
- 
--   Following the `WHATWG spec`_ that updates RFC 3986, ASCII newline
--   ``\n``, ``\r`` and tab ``\t`` characters are stripped from the URL.
-+   Following some of the `WHATWG spec`_ that updates RFC 3986, leading C0
-+   control and space characters are stripped from the URL. ``\n``,
-+   ``\r`` and tab ``\t`` characters are removed from the URL at any position.
-+
-+   .. warning::
-+
-+      :func:`urlsplit` does not perform validation.  See :ref:`URL parsing
-+      security <url-parsing-security>` for details.
- 
-    .. versionchanged:: 3.6
-       Out-of-range port numbers now raise :exc:`ValueError`, instead of
-@@ -338,6 +348,9 @@ or on combining URL components into a URL string.
-    .. versionchanged:: 3.10
-       ASCII newline and tab characters are stripped from the URL.
- 
-+   .. versionchanged:: 3.11.4
-+      Leading WHATWG C0 control and space characters are stripped from the URL.
-+
- .. _WHATWG spec: https://url.spec.whatwg.org/#concept-basic-url-parser
- 
- .. function:: urlunsplit(parts)
-@@ -414,6 +427,35 @@ or on combining URL components into a URL string.
-    or ``scheme://host/path``). If *url* is not a wrapped URL, it is returned
-    without changes.
- 
-+.. _url-parsing-security:
-+
-+URL parsing security
-+--------------------
-+
-+The :func:`urlsplit` and :func:`urlparse` APIs do not perform **validation** of
-+inputs.  They may not raise errors on inputs that other applications consider
-+invalid.  They may also succeed on some inputs that might not be considered
-+URLs elsewhere.  Their purpose is for practical functionality rather than
-+purity.
-+
-+Instead of raising an exception on unusual input, they may instead return some
-+component parts as empty strings. Or components may contain more than perhaps
-+they should.
-+
-+We recommend that users of these APIs where the values may be used anywhere
-+with security implications code defensively. Do some verification within your
-+code before trusting a returned component part.  Does that ``scheme`` make
-+sense?  Is that a sensible ``path``?  Is there anything strange about that
-+``hostname``?  etc.
-+
-+What constitutes a URL is not universally well defined.  Different applications
-+have different needs and desired constraints.  For instance the living `WHATWG
-+spec`_ describes what user facing web clients such as a web browser require.
-+While :rfc:`3986` is more general.  These functions incorporate some aspects of
-+both, but cannot be claimed compliant with either.  The APIs and existing user
-+code with expectations on specific behaviors predate both standards leading us
-+to be very cautious about making API behavior changes.
-+
- .. _parsing-ascii-encoded-bytes:
- 
- Parsing ASCII Encoded Bytes
-diff --git a/Lib/test/test_urlparse.py b/Lib/test/test_urlparse.py
-index b426110723..40f13d631c 100644
---- a/Lib/test/test_urlparse.py
-+++ b/Lib/test/test_urlparse.py
-@@ -649,6 +649,65 @@ def test_urlsplit_remove_unsafe_bytes(self):
-             self.assertEqual(p.scheme, "http")
-             self.assertEqual(p.geturl(), "http://www.python.org/javascript:alert('msg')/?query=something#fragment")
- 
-+    def test_urlsplit_strip_url(self):
-+        noise = bytes(range(0, 0x20 + 1))
-+        base_url = "http://User:Pass@www.python.org:080/doc/?query=yes#frag"
-+
-+        url = noise.decode("utf-8") + base_url
-+        p = urllib.parse.urlsplit(url)
-+        self.assertEqual(p.scheme, "http")
-+        self.assertEqual(p.netloc, "User:Pass@www.python.org:080")
-+        self.assertEqual(p.path, "/doc/")
-+        self.assertEqual(p.query, "query=yes")
-+        self.assertEqual(p.fragment, "frag")
-+        self.assertEqual(p.username, "User")
-+        self.assertEqual(p.password, "Pass")
-+        self.assertEqual(p.hostname, "www.python.org")
-+        self.assertEqual(p.port, 80)
-+        self.assertEqual(p.geturl(), base_url)
-+
-+        url = noise + base_url.encode("utf-8")
-+        p = urllib.parse.urlsplit(url)
-+        self.assertEqual(p.scheme, b"http")
-+        self.assertEqual(p.netloc, b"User:Pass@www.python.org:080")
-+        self.assertEqual(p.path, b"/doc/")
-+        self.assertEqual(p.query, b"query=yes")
-+        self.assertEqual(p.fragment, b"frag")
-+        self.assertEqual(p.username, b"User")
-+        self.assertEqual(p.password, b"Pass")
-+        self.assertEqual(p.hostname, b"www.python.org")
-+        self.assertEqual(p.port, 80)
-+        self.assertEqual(p.geturl(), base_url.encode("utf-8"))
-+
-+        # Test that trailing space is preserved as some applications rely on
-+        # this within query strings.
-+        query_spaces_url = "https://www.python.org:88/doc/?query=    "
-+        p = urllib.parse.urlsplit(noise.decode("utf-8") + query_spaces_url)
-+        self.assertEqual(p.scheme, "https")
-+        self.assertEqual(p.netloc, "www.python.org:88")
-+        self.assertEqual(p.path, "/doc/")
-+        self.assertEqual(p.query, "query=    ")
-+        self.assertEqual(p.port, 88)
-+        self.assertEqual(p.geturl(), query_spaces_url)
-+
-+        p = urllib.parse.urlsplit("www.pypi.org ")
-+        # That "hostname" gets considered a "path" due to the
-+        # trailing space and our existing logic...  YUCK...
-+        # and re-assembles via geturl aka unurlsplit into the original.
-+        # django.core.validators.URLValidator (at least through v3.2) relies on
-+        # this, for better or worse, to catch it in a ValidationError via its
-+        # regular expressions.
-+        # Here we test the basic round trip concept of such a trailing space.
-+        self.assertEqual(urllib.parse.urlunsplit(p), "www.pypi.org ")
-+
-+        # with scheme as cache-key
-+        url = "//www.python.org/"
-+        scheme = noise.decode("utf-8") + "https" + noise.decode("utf-8")
-+        for _ in range(2):
-+            p = urllib.parse.urlsplit(url, scheme=scheme)
-+            self.assertEqual(p.scheme, "https")
-+            self.assertEqual(p.geturl(), "https://www.python.org/")
-+
-     def test_attributes_bad_port(self):
-         """Check handling of invalid ports."""
-         for bytes in (False, True):
-@@ -656,7 +715,7 @@ def test_attributes_bad_port(self):
-                 for port in ("foo", "1.5", "-1", "0x10", "-0", "1_1", " 1", "1 ", "६"):
-                     with self.subTest(bytes=bytes, parse=parse, port=port):
-                         netloc = "www.example.net:" + port
--                        url = "http://" + netloc
-+                        url = "http://" + netloc + "/"
-                         if bytes:
-                             if netloc.isascii() and port.isascii():
-                                 netloc = netloc.encode("ascii")
-diff --git a/Lib/urllib/parse.py b/Lib/urllib/parse.py
-index 69631cbb81..4f06fd509e 100644
---- a/Lib/urllib/parse.py
-+++ b/Lib/urllib/parse.py
-@@ -25,6 +25,10 @@
- scenarios for parsing, and for backward compatibility purposes, some
- parsing quirks from older RFCs are retained. The testcases in
- test_urlparse.py provides a good indicator of parsing behavior.
-+
-+The WHATWG URL Parser spec should also be considered.  We are not compliant with
-+it either due to existing user code API behavior expectations (Hyrum's Law).
-+It serves as a useful guide when making changes.
- """
- 
- from collections import namedtuple
-@@ -79,6 +83,10 @@
-                 '0123456789'
-                 '+-.')
- 
-+# Leading and trailing C0 control and space to be stripped per WHATWG spec.
-+# == "".join([chr(i) for i in range(0, 0x20 + 1)])
-+_WHATWG_C0_CONTROL_OR_SPACE = '\x00\x01\x02\x03\x04\x05\x06\x07\x08\t\n\x0b\x0c\r\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f '
-+
- # Unsafe bytes to be removed per WHATWG spec
- _UNSAFE_URL_BYTES_TO_REMOVE = ['\t', '\r', '\n']
- 
-@@ -452,6 +460,10 @@ def urlsplit(url, scheme='', allow_fragments=True):
-     """
- 
-     url, scheme, _coerce_result = _coerce_args(url, scheme)
-+    # Only lstrip url as some applications rely on preserving trailing space.
-+    # (https://url.spec.whatwg.org/#concept-basic-url-parser would strip both)
-+    url = url.lstrip(_WHATWG_C0_CONTROL_OR_SPACE)
-+    scheme = scheme.strip(_WHATWG_C0_CONTROL_OR_SPACE)
- 
-     for b in _UNSAFE_URL_BYTES_TO_REMOVE:
-         url = url.replace(b, "")
-diff --git a/Misc/NEWS.d/next/Security/2023-03-07-20-59-17.gh-issue-102153.14CLSZ.rst b/Misc/NEWS.d/next/Security/2023-03-07-20-59-17.gh-issue-102153.14CLSZ.rst
-new file mode 100644
-index 0000000000..e57ac4ed3a
---- /dev/null
-+++ b/Misc/NEWS.d/next/Security/2023-03-07-20-59-17.gh-issue-102153.14CLSZ.rst
-@@ -0,0 +1,3 @@
-+:func:`urllib.parse.urlsplit` now strips leading C0 control and space
-+characters following the specification for URLs defined by WHATWG in
-+response to CVE-2023-24329. Patch by Illia Volochii.

python3.11.spec

@@ -13,11 +13,11 @@ URL: https://www.python.org/
 
 #  WARNING  When rebasing to a new Python version,
 #           remember to update the python3-docs package as well
-%global general_version %{pybasever}.3
+%global general_version %{pybasever}.4
 #global prerel ...
 %global upstream_version %{general_version}%{?prerel}
 Version: %{general_version}%{?prerel:~%{prerel}}
-Release: 2%{?dist}
+Release: 1%{?dist}
 License: Python-2.0.1
 
 
@@ -67,7 +67,7 @@ License: Python-2.0.1
 # If the rpmwheels condition is disabled, we use the bundled wheel packages
 # from Python with the versions below.
 # This needs to be manually updated when we update Python.
-%global pip_version 22.3.1
+%global pip_version 23.1.2
 %global setuptools_version 65.5.0
 
 # Expensive optimizations (mainly, profile-guided optimizations)
@@ -315,18 +315,6 @@ Patch251: 00251-change-user-install-location.patch
 # https://github.com/GrahamDumpleton/mod_wsgi/issues/730
 Patch371: 00371-revert-bpo-1596321-fix-threading-_shutdown-for-the-main-thread-gh-28549-gh-28589.patch
 
-# 00399 # 62614243969f1c717a02a1c65e55ef173ad9a6dd
-# CVE-2023-24329
-#
-# * gh-102153: Start stripping C0 control and space chars in `urlsplit` (GH-102508)
-#
-# `urllib.parse.urlsplit` has already been respecting the WHATWG spec a bit GH-25595.
-#
-# This adds more sanitizing to respect the "Remove any leading C0 control or space from input" [rule](https://url.spec.whatwg.org/GH-url-parsing:~:text=Remove%%20any%%20leading%%20and%%20trailing%%20C0%%20control%%20or%%20space%%20from%%20input.) in response to [CVE-2023-24329](https://nvd.nist.gov/vuln/detail/CVE-2023-24329).
-#
-# ---------
-Patch399: 00399-cve-2023-24329.patch
-
 # (New patches go here ^^^)
 #
 # When adding new patches to "python" and "python3" in Fedora, EL, etc.,
@@ -1615,6 +1603,9 @@ CheckPython optimized
 # ======================================================
 
 %changelog
+* Wed Jun 07 2023 Tomáš Hrnčiar <thrnciar@redhat.com> - 3.11.4-1
+- Update to 3.11.4
+
 * Wed May 24 2023 Lumír Balhar <lbalhar@redhat.com> - 3.11.3-2
 - Fix for CVE-2023-24329
 

sources

@@ -1,2 +1,2 @@
-SHA512 (Python-3.11.3.tar.xz) = a3bba4b69322a47bfeefe42ba0fd7331b5b67fd2ab41441e2219d16ef8c6f307f1a48977afd073c18cfd24ec6cb1bfe0c4bb4b273031eb524dc7e9fb5fbcc3b6
+SHA512 (Python-3.11.4.tar.xz) = 7eb14fecbf60824d10c22a9057584c3a142c2866f4af6caa2525c10c8bcb24e6e7afb32a44a0e118df0a2b2543d578c3b422ffd4a5fa317dfe6ea371cc7ee1ee
-SHA512 (Python-3.11.3.tar.xz.asc) = 34bfb6e74e2bbec15bf3f653e32a3d705961b5f724e3f4713cf9b6b530f9c9e7e94f5cf855798bdf9763235b97a60ec9ad554d24cdc793e21a0c39540b5818d8
+SHA512 (Python-3.11.4.tar.xz.asc) = 8ee82bf116b2cc7407e260eccf53e7fee4d7497165d0b9c3e59931c73f3b419bc0299b459eee9544a6e51e323ff0a6aa07827efd89f9c320b54556feeea04a78