[OE-core][whinlatter 00/11] Patch review

[OE-core][whinlatter 00/11] Patch review

[Yoann Congal]

Please review this set of changes for whinlatter and have comments back by
end of day Friday, January 9.

Note that this series contains the revert of 2 commits (merged on
whinlatter before they were on master)

Passed a-full on autobuilder(*):

https://autobuilder.yoctoproject.org/valkyrie/?#/builders/29/builds/3002

The following changes since commit 6c4c6d39ea3202d756acc13f8ce81b114a468541:

  cups: upgrade from 2.4.14 to 2.4.15 (2025-12-29 09:49:31 -0800)

are available in the Git repository at:

  https://git.openembedded.org/openembedded-core-contrib stable/whinlatter-nut
  https://git.openembedded.org/openembedded-core-contrib/log/?h=stable/whinlatter-nut

Alexander Kanavin (1):
  glib-2.0: upgrade 2.86.1 -> 2.86.3

Peter Marko (8):
  dropbear: patch CVE-2019-6111
  sqlite3: mark CVE-2025-29087 as patched
  python3-urllib3: patch CVE-2025-66418
  python3-urllib3: patch CVE-2025-66471
  python3: upgrade 3.13.9 -> 3.13.11
  libarchive: upgrade 3.8.3 -> 3.8.4
  libpng: upgrade 1.6.51 -> 1.6.52
  libpcap: upgrade 1.10.5 -> 1.10.6

Yoann Congal (2):
  Revert "populate_sdk_ext: keep SDK_TARGETS so SPDX/SBOM tasks remain
    in locked sigs"
  Revert "create-spdx-image-3.0: Image SPDX/SBOM tasks are retained for
    eSDK installation"

 .../create-spdx-image-3.0.bbclass             |   2 +-
 meta/classes-recipe/populate_sdk_ext.bbclass  |   9 -
 .../{libpcap_1.10.5.bb => libpcap_1.10.6.bb}  |   2 +-
 .../dropbear/dropbear/CVE-2019-6111.patch     | 157 +++
 .../recipes-core/dropbear/dropbear_2025.88.bb |   1 +
 ...t-write-bindir-into-pkg-config-files.patch |  10 +-
 ...0001-Fix-DATADIRNAME-on-uclibc-Linux.patch |   2 +-
 ...-gio-querymodules-as-libexec_PROGRAM.patch |   6 +-
 ...ng-about-deprecated-paths-in-schemas.patch |   2 +-
 ...ces.c-comment-out-a-build-host-only-.patch |   2 +-
 ...on-Run-atomics-test-on-clang-as-well.patch |   6 +-
 ...ot-enable-pidfd-features-on-native-g.patch |   6 +-
 ...dcode-python-path-into-various-tools.patch |   2 +-
 .../glib-2.0/files/relocate-modules.patch     |   8 +-
 .../glib-2.0/files/skip-timeout.patch         |   2 +-
 ...l_2.86.1.bb => glib-2.0-initial_2.86.3.bb} |   0
 ...{glib-2.0_2.86.1.bb => glib-2.0_2.86.3.bb} |   0
 meta/recipes-core/glib-2.0/glib.inc           |   2 +-
 .../python3-urllib3/CVE-2025-66418.patch      |  74 ++
 .../python3-urllib3/CVE-2025-66471.patch      | 930 ++++++++++++++++++
 .../python/python3-urllib3_2.5.0.bb           |   5 +
 .../{python3_3.13.9.bb => python3_3.13.11.bb} |   2 +-
 ...ibarchive_3.8.3.bb => libarchive_3.8.4.bb} |   2 +-
 .../{libpng_1.6.51.bb => libpng_1.6.52.bb}    |   2 +-
 .../sqlite/files/CVE-2025-3277.patch          |   1 +
 25 files changed, 1197 insertions(+), 38 deletions(-)
 rename meta/recipes-connectivity/libpcap/{libpcap_1.10.5.bb => libpcap_1.10.6.bb} (95%)
 create mode 100644 meta/recipes-core/dropbear/dropbear/CVE-2019-6111.patch
 rename meta/recipes-core/glib-2.0/{glib-2.0-initial_2.86.1.bb => glib-2.0-initial_2.86.3.bb} (100%)
 rename meta/recipes-core/glib-2.0/{glib-2.0_2.86.1.bb => glib-2.0_2.86.3.bb} (100%)
 create mode 100644 meta/recipes-devtools/python/python3-urllib3/CVE-2025-66418.patch
 create mode 100644 meta/recipes-devtools/python/python3-urllib3/CVE-2025-66471.patch
 rename meta/recipes-devtools/python/{python3_3.13.9.bb => python3_3.13.11.bb} (99%)
 rename meta/recipes-extended/libarchive/{libarchive_3.8.3.bb => libarchive_3.8.4.bb} (96%)
 rename meta/recipes-multimedia/libpng/{libpng_1.6.51.bb => libpng_1.6.52.bb} (97%)

[OE-core][whinlatter 01/11] dropbear: patch CVE-2019-6111

[Yoann Congal]

From: Peter Marko <peter.marko@siemens.com>

Pick patch mentioning this CVE number.

Signed-off-by: Peter Marko <peter.marko@siemens.com>
---
 .../dropbear/dropbear/CVE-2019-6111.patch     | 157 ++++++++++++++++++
 .../recipes-core/dropbear/dropbear_2025.88.bb |   1 +
 2 files changed, 158 insertions(+)
 create mode 100644 meta/recipes-core/dropbear/dropbear/CVE-2019-6111.patch

diff --git a/meta/recipes-core/dropbear/dropbear/CVE-2019-6111.patch b/meta/recipes-core/dropbear/dropbear/CVE-2019-6111.patch
new file mode 100644
index 0000000000..3ad968aa78
--- /dev/null
+++ b/meta/recipes-core/dropbear/dropbear/CVE-2019-6111.patch
@@ -0,0 +1,157 @@
+From 48a17cff6aa104b8e806ddb2191f83f1024060f1 Mon Sep 17 00:00:00 2001
+From: Matt Johnston <matt@ucc.asn.au>
+Date: Tue, 9 Dec 2025 22:59:19 +0900
+Subject: [PATCH] scp CVE-2019-6111 fix
+
+Cherry-pick from OpenSSH portable
+
+391ffc4b9d31 ("upstream: check in scp client that filenames sent during")
+
+upstream: check in scp client that filenames sent during
+
+remote->local directory copies satisfy the wildcard specified by the user.
+
+This checking provides some protection against a malicious server
+sending unexpected filenames, but it comes at a risk of rejecting wanted
+files due to differences between client and server wildcard expansion rules.
+
+For this reason, this also adds a new -T flag to disable the check.
+
+reported by Harry Sintonen
+fix approach suggested by markus@;
+has been in snaps for ~1wk courtesy deraadt@
+
+CVE: CVE-2019-6111
+Upstream-Status: Backport [https://github.com/mkj/dropbear/commit/48a17cff6aa104b8e806ddb2191f83f1024060f1]
+Signed-off-by: Peter Marko <peter.marko@siemens.com>
+---
+ src/scp.c | 38 +++++++++++++++++++++++++++++---------
+ 1 file changed, 29 insertions(+), 9 deletions(-)
+
+diff --git a/src/scp.c b/src/scp.c
+index 384f2cb..bf98986 100644
+--- a/src/scp.c
++++ b/src/scp.c
+@@ -76,6 +76,8 @@
+ #include "includes.h"
+ /*RCSID("$OpenBSD: scp.c,v 1.130 2006/01/31 10:35:43 djm Exp $");*/
+ 
++#include <fnmatch.h>
++
+ #include "atomicio.h"
+ #include "compat.h"
+ #include "scpmisc.h"
+@@ -291,14 +293,14 @@ void verifydir(char *);
+ 
+ uid_t userid;
+ int errs, remin, remout;
+-int pflag, iamremote, iamrecursive, targetshouldbedirectory;
++int Tflag, pflag, iamremote, iamrecursive, targetshouldbedirectory;
+ 
+ #define	CMDNEEDS	64
+ char cmd[CMDNEEDS];		/* must hold "rcp -r -p -d\0" */
+ 
+ int response(void);
+ void rsource(char *, struct stat *);
+-void sink(int, char *[]);
++void sink(int, char *[], const char *);
+ void source(int, char *[]);
+ void tolocal(int, char *[]);
+ void toremote(char *, int, char *[]);
+@@ -325,8 +327,8 @@ main(int argc, char **argv)
+ 	args.list = NULL;
+ 	addargs(&args, "%s", ssh_program);
+ 
+-	fflag = tflag = 0;
+-	while ((ch = getopt(argc, argv, "dfl:prtvBCc:i:P:q1246S:o:F:")) != -1)
++	fflag = Tflag = tflag = 0;
++	while ((ch = getopt(argc, argv, "dfl:prtTvBCc:i:P:q1246S:o:F:")) != -1)
+ 		switch (ch) {
+ 		/* User-visible flags. */
+ 		case '1':
+@@ -389,9 +391,12 @@ main(int argc, char **argv)
+ 			setmode(0, O_BINARY);
+ #endif
+ 			break;
++		case 'T':
++			Tflag = 1;
++			break;
+ 		default:
+ 			usage();
+-		}
++	}
+ 	argc -= optind;
+ 	argv += optind;
+ 
+@@ -409,7 +414,7 @@ main(int argc, char **argv)
+ 	}
+ 	if (tflag) {
+ 		/* Receive data. */
+-		sink(argc, argv);
++		sink(argc, argv, NULL);
+ 		exit(errs != 0);
+ 	}
+ 	if (argc < 2)
+@@ -589,7 +594,7 @@ tolocal(int argc, char **argv)
+ 			continue;
+ 		}
+ 		xfree(bp);
+-		sink(1, argv + argc - 1);
++		sink(1, argv + argc - 1, src);
+ 		(void) close(remin);
+ 		remin = remout = -1;
+ 	}
+@@ -822,7 +827,7 @@ bwlimit(int amount)
+ }
+ 
+ void
+-sink(int argc, char **argv)
++sink(int argc, char **argv, const char *src)
+ {
+ 	static BUF buffer;
+ 	struct stat stb;
+@@ -836,6 +841,7 @@ sink(int argc, char **argv)
+ 	off_t size, statbytes;
+ 	int setimes, targisdir, wrerrno = 0;
+ 	char ch, *cp, *np, *targ, *why, *vect[1], buf[2048];
++	char *src_copy = NULL, *restrict_pattern = NULL;
+ 	struct timeval tv[2];
+ 
+ #define	atime	tv[0]
+@@ -857,6 +863,17 @@ sink(int argc, char **argv)
+ 	(void) atomicio(vwrite, remout, "", 1);
+ 	if (stat(targ, &stb) == 0 && S_ISDIR(stb.st_mode))
+ 		targisdir = 1;
++	if (src != NULL && !iamrecursive && !Tflag) {
++		/*
++		 * Prepare to try to restrict incoming filenames to match
++		 * the requested destination file glob.
++		 */
++		if ((src_copy = strdup(src)) == NULL)
++			fatal("strdup failed");
++		if ((restrict_pattern = strrchr(src_copy, '/')) != NULL) {
++			*restrict_pattern++ = '\0';
++		}
++	}
+ 	for (first = 1;; first = 0) {
+ 		cp = buf;
+ 		if (atomicio(read, remin, cp, 1) != 1)
+@@ -939,6 +956,9 @@ sink(int argc, char **argv)
+ 			run_err("error: unexpected filename: %s", cp);
+ 			exit(1);
+ 		}
++		if (restrict_pattern != NULL &&
++		    fnmatch(restrict_pattern, cp, 0) != 0)
++			SCREWUP("filename does not match request");
+ 		if (targisdir) {
+ 			static char *namebuf = NULL;
+ 			static size_t cursize = 0;
+@@ -977,7 +997,7 @@ sink(int argc, char **argv)
+ 					goto bad;
+ 			}
+ 			vect[0] = xstrdup(np);
+-			sink(1, vect);
++			sink(1, vect, src);
+ 			if (setimes) {
+ 				setimes = 0;
+ 				if (utimes(vect[0], tv) < 0)
diff --git a/meta/recipes-core/dropbear/dropbear_2025.88.bb b/meta/recipes-core/dropbear/dropbear_2025.88.bb
index 72a886d907..05af557b21 100644
--- a/meta/recipes-core/dropbear/dropbear_2025.88.bb
+++ b/meta/recipes-core/dropbear/dropbear_2025.88.bb
@@ -21,6 +21,7 @@ SRC_URI = "http://matt.ucc.asn.au/dropbear/releases/dropbear-${PV}.tar.bz2 \
            file://dropbear.default \
            file://0001-Fix-proxycmd-without-netcat.patch \
            ${@bb.utils.contains('DISTRO_FEATURES', 'pam', '${PAM_SRC_URI}', '', d)} \
+           file://CVE-2019-6111.patch \
            "
 
 SRC_URI[sha256sum] = "783f50ea27b17c16da89578fafdb6decfa44bb8f6590e5698a4e4d3672dc53d4"

[OE-core][whinlatter 02/11] sqlite3: mark CVE-2025-29087 as patched

[Yoann Congal]

From: Peter Marko <peter.marko@siemens.com>

Description of CVE-2025-29087 and CVE-2025-3277 are very similar.
There is no link from NVD, but [1] and [2] from Debian mark these two
CVEs as duplicates with the same link for patch.

[1] https://security-tracker.debian.org/tracker/CVE-2025-29087
[2] https://security-tracker.debian.org/tracker/CVE-2025-3277

Signed-off-by: Peter Marko <peter.marko@siemens.com>
---
 meta/recipes-support/sqlite/files/CVE-2025-3277.patch | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-support/sqlite/files/CVE-2025-3277.patch b/meta/recipes-support/sqlite/files/CVE-2025-3277.patch
index a3e28465f5..625cf29d3e 100644
--- a/meta/recipes-support/sqlite/files/CVE-2025-3277.patch
+++ b/meta/recipes-support/sqlite/files/CVE-2025-3277.patch
@@ -7,6 +7,7 @@ Subject: [PATCH] Add a typecast to avoid 32-bit integer overflow in the
 FossilOrigin-Name: 498e3f1cf57f164fbd8380e92bf91b9f26d6aa05d092fcd135d754abf1e5b1b5
 
 CVE: CVE-2025-3277
+CVE: CVE-2025-29087
 Upstream-Status: Backport [https://github.com/sqlite/sqlite/commit/f4fc2ee20311a0a5141726c71d318ab52001c974]
 
 Signed-off-by: Ankur Tyagi <ankur.tyagi85@gmail.com>

[OE-core][whinlatter 03/11] python3-urllib3: patch CVE-2025-66418

[Yoann Congal]

From: Peter Marko <peter.marko@siemens.com>

Pick patch per [1].

[1] https://nvd.nist.gov/vuln/detail/CVE-2025-66418

Signed-off-by: Peter Marko <peter.marko@siemens.com>
---
 .../python3-urllib3/CVE-2025-66418.patch      | 74 +++++++++++++++++++
 .../python/python3-urllib3_2.5.0.bb           |  4 +
 2 files changed, 78 insertions(+)
 create mode 100644 meta/recipes-devtools/python/python3-urllib3/CVE-2025-66418.patch

diff --git a/meta/recipes-devtools/python/python3-urllib3/CVE-2025-66418.patch b/meta/recipes-devtools/python/python3-urllib3/CVE-2025-66418.patch
new file mode 100644
index 0000000000..71fc44e4f9
--- /dev/null
+++ b/meta/recipes-devtools/python/python3-urllib3/CVE-2025-66418.patch
@@ -0,0 +1,74 @@
+From 24d7b67eac89f94e11003424bcf0d8f7b72222a8 Mon Sep 17 00:00:00 2001
+From: Illia Volochii <illia.volochii@gmail.com>
+Date: Fri, 5 Dec 2025 16:41:33 +0200
+Subject: [PATCH] Merge commit from fork
+
+* Add a hard-coded limit for the decompression chain
+
+* Reuse new list
+
+CVE: CVE-2025-66418
+Upstream-Status: Backport [https://github.com/urllib3/urllib3/commit/24d7b67eac89f94e11003424bcf0d8f7b72222a8]
+Signed-off-by: Peter Marko <peter.marko@siemens.com>
+---
+ changelog/GHSA-gm62-xv2j-4w53.security.rst |  4 ++++
+ src/urllib3/response.py                    | 12 +++++++++++-
+ test/test_response.py                      | 10 ++++++++++
+ 3 files changed, 25 insertions(+), 1 deletion(-)
+ create mode 100644 changelog/GHSA-gm62-xv2j-4w53.security.rst
+
+diff --git a/changelog/GHSA-gm62-xv2j-4w53.security.rst b/changelog/GHSA-gm62-xv2j-4w53.security.rst
+new file mode 100644
+index 00000000..6646eaa3
+--- /dev/null
++++ b/changelog/GHSA-gm62-xv2j-4w53.security.rst
+@@ -0,0 +1,4 @@
++Fixed a security issue where an attacker could compose an HTTP response with
++virtually unlimited links in the ``Content-Encoding`` header, potentially
++leading to a denial of service (DoS) attack by exhausting system resources
++during decoding. The number of allowed chained encodings is now limited to 5.
+diff --git a/src/urllib3/response.py b/src/urllib3/response.py
+index 4ba42136..069f726c 100644
+--- a/src/urllib3/response.py
++++ b/src/urllib3/response.py
+@@ -220,8 +220,18 @@ class MultiDecoder(ContentDecoder):
+         they were applied.
+     """
+ 
++    # Maximum allowed number of chained HTTP encodings in the
++    # Content-Encoding header.
++    max_decode_links = 5
++
+     def __init__(self, modes: str) -> None:
+-        self._decoders = [_get_decoder(m.strip()) for m in modes.split(",")]
++        encodings = [m.strip() for m in modes.split(",")]
++        if len(encodings) > self.max_decode_links:
++            raise DecodeError(
++                "Too many content encodings in the chain: "
++                f"{len(encodings)} > {self.max_decode_links}"
++            )
++        self._decoders = [_get_decoder(e) for e in encodings]
+ 
+     def flush(self) -> bytes:
+         return self._decoders[0].flush()
+diff --git a/test/test_response.py b/test/test_response.py
+index 9592fdd9..d824ae70 100644
+--- a/test/test_response.py
++++ b/test/test_response.py
+@@ -584,6 +584,16 @@ class TestResponse:
+         assert r.read(9 * 37) == b"foobarbaz" * 37
+         assert r.read() == b""
+ 
++    def test_read_multi_decoding_too_many_links(self) -> None:
++        fp = BytesIO(b"foo")
++        with pytest.raises(
++            DecodeError, match="Too many content encodings in the chain: 6 > 5"
++        ):
++            HTTPResponse(
++                fp,
++                headers={"content-encoding": "gzip, deflate, br, zstd, gzip, deflate"},
++            )
++
+     def test_body_blob(self) -> None:
+         resp = HTTPResponse(b"foo")
+         assert resp.data == b"foo"
diff --git a/meta/recipes-devtools/python/python3-urllib3_2.5.0.bb b/meta/recipes-devtools/python/python3-urllib3_2.5.0.bb
index 62fdf8e345..c39e9676e8 100644
--- a/meta/recipes-devtools/python/python3-urllib3_2.5.0.bb
+++ b/meta/recipes-devtools/python/python3-urllib3_2.5.0.bb
@@ -7,6 +7,10 @@ SRC_URI[sha256sum] = "3fc47733c7e419d4bc3f6b3dc2b4f890bb743906a30d56ba4a5bfa4bbf
 
 inherit pypi python_hatchling
 
+SRC_URI += "\
+    file://CVE-2025-66418.patch \
+"
+
 DEPENDS += "python3-hatch-vcs-native"
 
 PACKAGECONFIG ??= ""

[OE-core][whinlatter 04/11] python3-urllib3: patch CVE-2025-66471

[Yoann Congal]

From: Peter Marko <peter.marko@siemens.com>

Pick patch per [1].

[1] https://nvd.nist.gov/vuln/detail/CVE-2025-66471

Signed-off-by: Peter Marko <peter.marko@siemens.com>
---
 .../python3-urllib3/CVE-2025-66471.patch      | 930 ++++++++++++++++++
 .../python/python3-urllib3_2.5.0.bb           |   1 +
 2 files changed, 931 insertions(+)
 create mode 100644 meta/recipes-devtools/python/python3-urllib3/CVE-2025-66471.patch

diff --git a/meta/recipes-devtools/python/python3-urllib3/CVE-2025-66471.patch b/meta/recipes-devtools/python/python3-urllib3/CVE-2025-66471.patch
new file mode 100644
index 0000000000..2f8bc4fc92
--- /dev/null
+++ b/meta/recipes-devtools/python/python3-urllib3/CVE-2025-66471.patch
@@ -0,0 +1,930 @@
+From c19571de34c47de3a766541b041637ba5f716ed7 Mon Sep 17 00:00:00 2001
+From: Illia Volochii <illia.volochii@gmail.com>
+Date: Fri, 5 Dec 2025 16:40:41 +0200
+Subject: [PATCH] Merge commit from fork
+
+* Prevent decompression bomb for zstd in Python 3.14
+
+* Add experimental `decompress_iter` for Brotli
+
+* Update changes for Brotli
+
+* Add `GzipDecoder.decompress_iter`
+
+* Test https://github.com/python-hyper/brotlicffi/pull/207
+
+* Pin Brotli
+
+* Add `decompress_iter` to all decoders and make tests pass
+
+* Pin brotlicffi to an official release
+
+* Revert changes to response.py
+
+* Add `max_length` parameter to all `decompress` methods
+
+* Fix the `test_brotlipy` session
+
+* Unset `_data` on gzip error
+
+* Add a test for memory usage
+
+* Test more methods
+
+* Fix the test for `stream`
+
+* Cover more lines with tests
+
+* Add more coverage
+
+* Make `read1` a bit more efficient
+
+* Fix PyPy tests for Brotli
+
+* Revert an unnecessarily moved check
+
+* Add some comments
+
+* Leave just one `self._obj.decompress` call in `GzipDecoder`
+
+* Refactor test params
+
+* Test reads with all data already in the decompressor
+
+* Prevent needless copying of data decoded with `max_length`
+
+* Rename the changed test
+
+* Note that responses of unknown length should be streamed too
+
+* Add a changelog entry
+
+* Avoid returning a memory view from `BytesQueueBuffer`
+
+* Add one more note to the changelog entry
+
+CVE: CVE-2025-66471
+Upstream-Status: Backport [https://github.com/urllib3/urllib3/commit/c19571de34c47de3a766541b041637ba5f716ed7]
+Signed-off-by: Peter Marko <peter.marko@siemens.com>
+---
+ CHANGES.rst             |  22 ++++
+ docs/advanced-usage.rst |   3 +-
+ docs/user-guide.rst     |   4 +-
+ pyproject.toml          |   5 +-
+ src/urllib3/response.py | 278 ++++++++++++++++++++++++++++++++++------
+ test/test_response.py   | 269 +++++++++++++++++++++++++++++++++++++-
+ 6 files changed, 532 insertions(+), 49 deletions(-)
+
+diff --git a/CHANGES.rst b/CHANGES.rst
+index add194eb..345476f3 100644
+--- a/CHANGES.rst
++++ b/CHANGES.rst
+@@ -1,3 +1,25 @@
++2.6.0 (TBD)
++==================
++
++Bugfixes
++--------
++
++- Fixed a security issue where streaming API could improperly handle highly
++  compressed HTTP content ("decompression bombs") leading to excessive resource
++  consumption even when a small amount of data was requested. Reading small
++  chunks of compressed data is safer and much more efficient now.
++
++.. caution::
++  - If urllib3 is not installed with the optional `urllib3[brotli]` extra, but
++    your environment contains a Brotli/brotlicffi/brotlipy package anyway, make
++    sure to upgrade it to at least Brotli 1.2.0 or brotlicffi 1.2.0.0 to
++    benefit from the security fixes and avoid warnings. Prefer using
++    `urllib3[brotli]` to install a compatible Brotli package automatically.
++
++  - If you use custom decompressors, please make sure to update them to
++    respect the changed API of ``urllib3.response.ContentDecoder``.
++
++
+ 2.5.0 (2025-06-18)
+ ==================
+ 
+diff --git a/docs/advanced-usage.rst b/docs/advanced-usage.rst
+index ff773662..3ab4fcf3 100644
+--- a/docs/advanced-usage.rst
++++ b/docs/advanced-usage.rst
+@@ -66,7 +66,8 @@ When using ``preload_content=True`` (the default setting) the
+ response body will be read immediately into memory and the HTTP connection
+ will be released back into the pool without manual intervention.
+ 
+-However, when dealing with large responses it's often better to stream the response
++However, when dealing with responses of large or unknown length,
++it's often better to stream the response
+ content using ``preload_content=False``. Setting ``preload_content`` to ``False`` means
+ that urllib3 will only read from the socket when data is requested.
+ 
+diff --git a/docs/user-guide.rst b/docs/user-guide.rst
+index 5c78c8af..1d9d0bbd 100644
+--- a/docs/user-guide.rst
++++ b/docs/user-guide.rst
+@@ -145,8 +145,8 @@ to a byte string representing the response content:
+     print(resp.data)
+     # b"\xaa\xa5H?\x95\xe9\x9b\x11"
+ 
+-.. note:: For larger responses, it's sometimes better to :ref:`stream <stream>`
+-    the response.
++.. note:: For responses of large or unknown length, it's sometimes better to
++    :ref:`stream <stream>` the response.
+ 
+ Using io Wrappers with Response Content
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+diff --git a/pyproject.toml b/pyproject.toml
+index c9aa6d13..45538a6e 100644
+--- a/pyproject.toml
++++ b/pyproject.toml
+@@ -41,8 +41,8 @@ dynamic = ["version"]
+ 
+ [project.optional-dependencies]
+ brotli = [
+-  "brotli>=1.0.9; platform_python_implementation == 'CPython'",
+-  "brotlicffi>=0.8.0; platform_python_implementation != 'CPython'"
++  "brotli>=1.2.0; platform_python_implementation == 'CPython'",
++  "brotlicffi>=1.2.0.0; platform_python_implementation != 'CPython'"
+ ]
+ # Once we drop support for Python 3.13 this extra can be removed.
+ # We'll need a deprecation period for the 'zstandard' module support
+@@ -160,6 +160,7 @@ filterwarnings = [
+     '''default:ssl\.PROTOCOL_TLSv1_1 is deprecated:DeprecationWarning''',
+     '''default:ssl\.PROTOCOL_TLSv1_2 is deprecated:DeprecationWarning''',
+     '''default:ssl NPN is deprecated, use ALPN instead:DeprecationWarning''',
++    '''default:Brotli >= 1.2.0 is required to prevent decompression bombs\.:urllib3.exceptions.DependencyWarning''',
+     # https://github.com/SeleniumHQ/selenium/issues/13328
+     '''default:unclosed file <_io\.BufferedWriter name='/dev/null'>:ResourceWarning''',
+     # https://github.com/SeleniumHQ/selenium/issues/14686
+diff --git a/src/urllib3/response.py b/src/urllib3/response.py
+index 3df98184..4ba42136 100644
+--- a/src/urllib3/response.py
++++ b/src/urllib3/response.py
+@@ -33,6 +33,7 @@ from .connection import BaseSSLError, HTTPConnection, HTTPException
+ from .exceptions import (
+     BodyNotHttplibCompatible,
+     DecodeError,
++    DependencyWarning,
+     HTTPError,
+     IncompleteRead,
+     InvalidChunkLength,
+@@ -52,7 +53,11 @@ log = logging.getLogger(__name__)
+ 
+ 
+ class ContentDecoder:
+-    def decompress(self, data: bytes) -> bytes:
++    def decompress(self, data: bytes, max_length: int = -1) -> bytes:
++        raise NotImplementedError()
++
++    @property
++    def has_unconsumed_tail(self) -> bool:
+         raise NotImplementedError()
+ 
+     def flush(self) -> bytes:
+@@ -62,30 +67,57 @@ class ContentDecoder:
+ class DeflateDecoder(ContentDecoder):
+     def __init__(self) -> None:
+         self._first_try = True
+-        self._data = b""
++        self._first_try_data = b""
++        self._unfed_data = b""
+         self._obj = zlib.decompressobj()
+ 
+-    def decompress(self, data: bytes) -> bytes:
+-        if not data:
++    def decompress(self, data: bytes, max_length: int = -1) -> bytes:
++        data = self._unfed_data + data
++        self._unfed_data = b""
++        if not data and not self._obj.unconsumed_tail:
+             return data
++        original_max_length = max_length
++        if original_max_length < 0:
++            max_length = 0
++        elif original_max_length == 0:
++            # We should not pass 0 to the zlib decompressor because 0 is
++            # the default value that will make zlib decompress without a
++            # length limit.
++            # Data should be stored for subsequent calls.
++            self._unfed_data = data
++            return b""
+ 
++        # Subsequent calls always reuse `self._obj`. zlib requires
++        # passing the unconsumed tail if decompression is to continue.
+         if not self._first_try:
+-            return self._obj.decompress(data)
++            return self._obj.decompress(
++                self._obj.unconsumed_tail + data, max_length=max_length
++            )
+ 
+-        self._data += data
++        # First call tries with RFC 1950 ZLIB format.
++        self._first_try_data += data
+         try:
+-            decompressed = self._obj.decompress(data)
++            decompressed = self._obj.decompress(data, max_length=max_length)
+             if decompressed:
+                 self._first_try = False
+-                self._data = None  # type: ignore[assignment]
++                self._first_try_data = b""
+             return decompressed
++        # On failure, it falls back to RFC 1951 DEFLATE format.
+         except zlib.error:
+             self._first_try = False
+             self._obj = zlib.decompressobj(-zlib.MAX_WBITS)
+             try:
+-                return self.decompress(self._data)
++                return self.decompress(
++                    self._first_try_data, max_length=original_max_length
++                )
+             finally:
+-                self._data = None  # type: ignore[assignment]
++                self._first_try_data = b""
++
++    @property
++    def has_unconsumed_tail(self) -> bool:
++        return bool(self._unfed_data) or (
++            bool(self._obj.unconsumed_tail) and not self._first_try
++        )
+ 
+     def flush(self) -> bytes:
+         return self._obj.flush()
+@@ -101,27 +133,61 @@ class GzipDecoder(ContentDecoder):
+     def __init__(self) -> None:
+         self._obj = zlib.decompressobj(16 + zlib.MAX_WBITS)
+         self._state = GzipDecoderState.FIRST_MEMBER
++        self._unconsumed_tail = b""
+ 
+-    def decompress(self, data: bytes) -> bytes:
++    def decompress(self, data: bytes, max_length: int = -1) -> bytes:
+         ret = bytearray()
+-        if self._state == GzipDecoderState.SWALLOW_DATA or not data:
++        if self._state == GzipDecoderState.SWALLOW_DATA:
+             return bytes(ret)
++
++        if max_length == 0:
++            # We should not pass 0 to the zlib decompressor because 0 is
++            # the default value that will make zlib decompress without a
++            # length limit.
++            # Data should be stored for subsequent calls.
++            self._unconsumed_tail += data
++            return b""
++
++        # zlib requires passing the unconsumed tail to the subsequent
++        # call if decompression is to continue.
++        data = self._unconsumed_tail + data
++        if not data and self._obj.eof:
++            return bytes(ret)
++
+         while True:
+             try:
+-                ret += self._obj.decompress(data)
++                ret += self._obj.decompress(
++                    data, max_length=max(max_length - len(ret), 0)
++                )
+             except zlib.error:
+                 previous_state = self._state
+                 # Ignore data after the first error
+                 self._state = GzipDecoderState.SWALLOW_DATA
++                self._unconsumed_tail = b""
+                 if previous_state == GzipDecoderState.OTHER_MEMBERS:
+                     # Allow trailing garbage acceptable in other gzip clients
+                     return bytes(ret)
+                 raise
+-            data = self._obj.unused_data
++
++            self._unconsumed_tail = data = (
++                self._obj.unconsumed_tail or self._obj.unused_data
++            )
++            if max_length > 0 and len(ret) >= max_length:
++                break
++
+             if not data:
+                 return bytes(ret)
+-            self._state = GzipDecoderState.OTHER_MEMBERS
+-            self._obj = zlib.decompressobj(16 + zlib.MAX_WBITS)
++            # When the end of a gzip member is reached, a new decompressor
++            # must be created for unused (possibly future) data.
++            if self._obj.eof:
++                self._state = GzipDecoderState.OTHER_MEMBERS
++                self._obj = zlib.decompressobj(16 + zlib.MAX_WBITS)
++
++        return bytes(ret)
++
++    @property
++    def has_unconsumed_tail(self) -> bool:
++        return bool(self._unconsumed_tail)
+ 
+     def flush(self) -> bytes:
+         return self._obj.flush()
+@@ -136,9 +202,35 @@ if brotli is not None:
+         def __init__(self) -> None:
+             self._obj = brotli.Decompressor()
+             if hasattr(self._obj, "decompress"):
+-                setattr(self, "decompress", self._obj.decompress)
++                setattr(self, "_decompress", self._obj.decompress)
+             else:
+-                setattr(self, "decompress", self._obj.process)
++                setattr(self, "_decompress", self._obj.process)
++
++        # Requires Brotli >= 1.2.0 for `output_buffer_limit`.
++        def _decompress(self, data: bytes, output_buffer_limit: int = -1) -> bytes:
++            raise NotImplementedError()
++
++        def decompress(self, data: bytes, max_length: int = -1) -> bytes:
++            try:
++                if max_length > 0:
++                    return self._decompress(data, output_buffer_limit=max_length)
++                else:
++                    return self._decompress(data)
++            except TypeError:
++                # Fallback for Brotli/brotlicffi/brotlipy versions without
++                # the `output_buffer_limit` parameter.
++                warnings.warn(
++                    "Brotli >= 1.2.0 is required to prevent decompression bombs.",
++                    DependencyWarning,
++                )
++                return self._decompress(data)
++
++        @property
++        def has_unconsumed_tail(self) -> bool:
++            try:
++                return not self._obj.can_accept_more_data()
++            except AttributeError:
++                return False
+ 
+         def flush(self) -> bytes:
+             if hasattr(self._obj, "flush"):
+@@ -156,16 +248,46 @@ try:
+         def __init__(self) -> None:
+             self._obj = zstd.ZstdDecompressor()
+ 
+-        def decompress(self, data: bytes) -> bytes:
+-            if not data:
++        def decompress(self, data: bytes, max_length: int = -1) -> bytes:
++            if not data and not self.has_unconsumed_tail:
+                 return b""
+-            data_parts = [self._obj.decompress(data)]
+-            while self._obj.eof and self._obj.unused_data:
+-                unused_data = self._obj.unused_data
++            if self._obj.eof:
++                data = self._obj.unused_data + data
+                 self._obj = zstd.ZstdDecompressor()
+-                data_parts.append(self._obj.decompress(unused_data))
++            part = self._obj.decompress(data, max_length=max_length)
++            length = len(part)
++            data_parts = [part]
++            # Every loop iteration is supposed to read data from a separate frame.
++            # The loop breaks when:
++            #   - enough data is read;
++            #   - no more unused data is available;
++            #   - end of the last read frame has not been reached (i.e.,
++            #     more data has to be fed).
++            while (
++                self._obj.eof
++                and self._obj.unused_data
++                and (max_length < 0 or length < max_length)
++            ):
++                unused_data = self._obj.unused_data
++                if not self._obj.needs_input:
++                    self._obj = zstd.ZstdDecompressor()
++                part = self._obj.decompress(
++                    unused_data,
++                    max_length=(max_length - length) if max_length > 0 else -1,
++                )
++                if part_length := len(part):
++                    data_parts.append(part)
++                    length += part_length
++                elif self._obj.needs_input:
++                    break
+             return b"".join(data_parts)
+ 
++        @property
++        def has_unconsumed_tail(self) -> bool:
++            return not (self._obj.needs_input or self._obj.eof) or bool(
++                self._obj.unused_data
++            )
++
+         def flush(self) -> bytes:
+             if not self._obj.eof:
+                 raise DecodeError("Zstandard data is incomplete")
+@@ -236,10 +358,35 @@ class MultiDecoder(ContentDecoder):
+     def flush(self) -> bytes:
+         return self._decoders[0].flush()
+ 
+-    def decompress(self, data: bytes) -> bytes:
+-        for d in reversed(self._decoders):
+-            data = d.decompress(data)
+-        return data
++    def decompress(self, data: bytes, max_length: int = -1) -> bytes:
++        if max_length <= 0:
++            for d in reversed(self._decoders):
++                data = d.decompress(data)
++            return data
++
++        ret = bytearray()
++        # Every while loop iteration goes through all decoders once.
++        # It exits when enough data is read or no more data can be read.
++        # It is possible that the while loop iteration does not produce
++        # any data because we retrieve up to `max_length` from every
++        # decoder, and the amount of bytes may be insufficient for the
++        # next decoder to produce enough/any output.
++        while True:
++            any_data = False
++            for d in reversed(self._decoders):
++                data = d.decompress(data, max_length=max_length - len(ret))
++                if data:
++                    any_data = True
++                # We should not break when no data is returned because
++                # next decoders may produce data even with empty input.
++            ret += data
++            if not any_data or len(ret) >= max_length:
++                return bytes(ret)
++            data = b""
++
++    @property
++    def has_unconsumed_tail(self) -> bool:
++        return any(d.has_unconsumed_tail for d in self._decoders)
+ 
+ 
+ def _get_decoder(mode: str) -> ContentDecoder:
+@@ -272,9 +419,6 @@ class BytesQueueBuffer:
+ 
+      * self.buffer, which contains the full data
+      * the largest chunk that we will copy in get()
+-
+-    The worst case scenario is a single chunk, in which case we'll make a full copy of
+-    the data inside get().
+     """
+ 
+     def __init__(self) -> None:
+@@ -296,6 +440,10 @@ class BytesQueueBuffer:
+         elif n < 0:
+             raise ValueError("n should be > 0")
+ 
++        if len(self.buffer[0]) == n and isinstance(self.buffer[0], bytes):
++            self._size -= n
++            return self.buffer.popleft()
++
+         fetched = 0
+         ret = io.BytesIO()
+         while fetched < n:
+@@ -502,7 +650,11 @@ class BaseHTTPResponse(io.IOBase):
+                     self._decoder = _get_decoder(content_encoding)
+ 
+     def _decode(
+-        self, data: bytes, decode_content: bool | None, flush_decoder: bool
++        self,
++        data: bytes,
++        decode_content: bool | None,
++        flush_decoder: bool,
++        max_length: int | None = None,
+     ) -> bytes:
+         """
+         Decode the data passed in and potentially flush the decoder.
+@@ -515,9 +667,12 @@ class BaseHTTPResponse(io.IOBase):
+                 )
+             return data
+ 
++        if max_length is None or flush_decoder:
++            max_length = -1
++
+         try:
+             if self._decoder:
+-                data = self._decoder.decompress(data)
++                data = self._decoder.decompress(data, max_length=max_length)
+                 self._has_decoded_content = True
+         except self.DECODER_ERROR_CLASSES as e:
+             content_encoding = self.headers.get("content-encoding", "").lower()
+@@ -984,6 +1139,14 @@ class HTTPResponse(BaseHTTPResponse):
+         elif amt is not None:
+             cache_content = False
+ 
++            if self._decoder and self._decoder.has_unconsumed_tail:
++                decoded_data = self._decode(
++                    b"",
++                    decode_content,
++                    flush_decoder=False,
++                    max_length=amt - len(self._decoded_buffer),
++                )
++                self._decoded_buffer.put(decoded_data)
+             if len(self._decoded_buffer) >= amt:
+                 return self._decoded_buffer.get(amt)
+ 
+@@ -991,7 +1154,11 @@ class HTTPResponse(BaseHTTPResponse):
+ 
+         flush_decoder = amt is None or (amt != 0 and not data)
+ 
+-        if not data and len(self._decoded_buffer) == 0:
++        if (
++            not data
++            and len(self._decoded_buffer) == 0
++            and not (self._decoder and self._decoder.has_unconsumed_tail)
++        ):
+             return data
+ 
+         if amt is None:
+@@ -1008,7 +1175,12 @@ class HTTPResponse(BaseHTTPResponse):
+                     )
+                 return data
+ 
+-            decoded_data = self._decode(data, decode_content, flush_decoder)
++            decoded_data = self._decode(
++                data,
++                decode_content,
++                flush_decoder,
++                max_length=amt - len(self._decoded_buffer),
++            )
+             self._decoded_buffer.put(decoded_data)
+ 
+             while len(self._decoded_buffer) < amt and data:
+@@ -1016,7 +1188,12 @@ class HTTPResponse(BaseHTTPResponse):
+                 # For example, the GZ file header takes 10 bytes, we don't want to read
+                 # it one byte at a time
+                 data = self._raw_read(amt)
+-                decoded_data = self._decode(data, decode_content, flush_decoder)
++                decoded_data = self._decode(
++                    data,
++                    decode_content,
++                    flush_decoder,
++                    max_length=amt - len(self._decoded_buffer),
++                )
+                 self._decoded_buffer.put(decoded_data)
+             data = self._decoded_buffer.get(amt)
+ 
+@@ -1051,6 +1228,20 @@ class HTTPResponse(BaseHTTPResponse):
+                     "Calling read1(decode_content=False) is not supported after "
+                     "read1(decode_content=True) was called."
+                 )
++            if (
++                self._decoder
++                and self._decoder.has_unconsumed_tail
++                and (amt is None or len(self._decoded_buffer) < amt)
++            ):
++                decoded_data = self._decode(
++                    b"",
++                    decode_content,
++                    flush_decoder=False,
++                    max_length=(
++                        amt - len(self._decoded_buffer) if amt is not None else None
++                    ),
++                )
++                self._decoded_buffer.put(decoded_data)
+             if len(self._decoded_buffer) > 0:
+                 if amt is None:
+                     return self._decoded_buffer.get_all()
+@@ -1066,7 +1257,9 @@ class HTTPResponse(BaseHTTPResponse):
+         self._init_decoder()
+         while True:
+             flush_decoder = not data
+-            decoded_data = self._decode(data, decode_content, flush_decoder)
++            decoded_data = self._decode(
++                data, decode_content, flush_decoder, max_length=amt
++            )
+             self._decoded_buffer.put(decoded_data)
+             if decoded_data or flush_decoder:
+                 break
+@@ -1097,7 +1290,11 @@ class HTTPResponse(BaseHTTPResponse):
+         if self.chunked and self.supports_chunked_reads():
+             yield from self.read_chunked(amt, decode_content=decode_content)
+         else:
+-            while not is_fp_closed(self._fp) or len(self._decoded_buffer) > 0:
++            while (
++                not is_fp_closed(self._fp)
++                or len(self._decoded_buffer) > 0
++                or (self._decoder and self._decoder.has_unconsumed_tail)
++            ):
+                 data = self.read(amt=amt, decode_content=decode_content)
+ 
+                 if data:
+@@ -1260,7 +1457,10 @@ class HTTPResponse(BaseHTTPResponse):
+                     break
+                 chunk = self._handle_chunk(amt)
+                 decoded = self._decode(
+-                    chunk, decode_content=decode_content, flush_decoder=False
++                    chunk,
++                    decode_content=decode_content,
++                    flush_decoder=False,
++                    max_length=amt,
+                 )
+                 if decoded:
+                     yield decoded
+diff --git a/test/test_response.py b/test/test_response.py
+index c97fdff0..9592fdd9 100644
+--- a/test/test_response.py
++++ b/test/test_response.py
+@@ -1,6 +1,7 @@
+ from __future__ import annotations
+ 
+ import contextlib
++import gzip
+ import http.client as httplib
+ import socket
+ import ssl
+@@ -43,6 +44,26 @@ def zstd_compress(data: bytes) -> bytes:
+     return zstd.compress(data)  # type: ignore[no-any-return]
+ 
+ 
++def deflate2_compress(data: bytes) -> bytes:
++    compressor = zlib.compressobj(6, zlib.DEFLATED, -zlib.MAX_WBITS)
++    return compressor.compress(data) + compressor.flush()
++
++
++if brotli:
++    try:
++        brotli.Decompressor().process(b"", output_buffer_limit=1024)
++        _brotli_gte_1_2_0_available = True
++    except (AttributeError, TypeError):
++        _brotli_gte_1_2_0_available = False
++else:
++    _brotli_gte_1_2_0_available = False
++try:
++    zstd_compress(b"")
++    _zstd_available = True
++except ModuleNotFoundError:
++    _zstd_available = False
++
++
+ class TestBytesQueueBuffer:
+     def test_single_chunk(self) -> None:
+         buffer = BytesQueueBuffer()
+@@ -118,12 +139,19 @@ class TestBytesQueueBuffer:
+ 
+         assert len(get_func(buffer)) == 10 * 2**20
+ 
++    @pytest.mark.parametrize(
++        "get_func",
++        (lambda b: b.get(len(b)), lambda b: b.get_all()),
++        ids=("get", "get_all"),
++    )
+     @pytest.mark.limit_memory("10.01 MB", current_thread_only=True)
+-    def test_get_all_memory_usage_single_chunk(self) -> None:
++    def test_memory_usage_single_chunk(
++        self, get_func: typing.Callable[[BytesQueueBuffer], bytes]
++    ) -> None:
+         buffer = BytesQueueBuffer()
+         chunk = bytes(10 * 2**20)  # 10 MiB
+         buffer.put(chunk)
+-        assert buffer.get_all() is chunk
++        assert get_func(buffer) is chunk
+ 
+ 
+ # A known random (i.e, not-too-compressible) payload generated with:
+@@ -426,7 +454,26 @@ class TestResponse:
+         assert r.data == b"foo"
+ 
+     @onlyZstd()
+-    def test_decode_multiframe_zstd(self) -> None:
++    @pytest.mark.parametrize(
++        "read_amt",
++        (
++            # Read all data at once.
++            None,
++            # Read one byte at a time, data of frames will be returned
++            # separately.
++            1,
++            # Read two bytes at a time, the second read should return
++            # data from both frames.
++            2,
++            # Read three bytes at a time, the whole frames will be
++            # returned separately in two calls.
++            3,
++            # Read four bytes at a time, the first read should return
++            # data from the first frame and a part of the second frame.
++            4,
++        ),
++    )
++    def test_decode_multiframe_zstd(self, read_amt: int | None) -> None:
+         data = (
+             # Zstandard frame
+             zstd_compress(b"foo")
+@@ -441,8 +488,57 @@ class TestResponse:
+         )
+ 
+         fp = BytesIO(data)
+-        r = HTTPResponse(fp, headers={"content-encoding": "zstd"})
+-        assert r.data == b"foobar"
++        result = bytearray()
++        r = HTTPResponse(
++            fp, headers={"content-encoding": "zstd"}, preload_content=False
++        )
++        total_length = 6
++        while len(result) < total_length:
++            chunk = r.read(read_amt, decode_content=True)
++            if read_amt is None:
++                assert len(chunk) == total_length
++            else:
++                assert len(chunk) == min(read_amt, total_length - len(result))
++            result += chunk
++        assert bytes(result) == b"foobar"
++
++    @onlyZstd()
++    def test_decode_multiframe_zstd_with_max_length_close_to_compressed_data_size(
++        self,
++    ) -> None:
++        """
++        Test decoding when the first read from the socket returns all
++        the compressed frames, but then it has to be decompressed in a
++        couple of read calls.
++        """
++        data = (
++            # Zstandard frame
++            zstd_compress(b"x" * 1024)
++            # skippable frame (must be ignored)
++            + bytes.fromhex(
++                "50 2A 4D 18"  # Magic_Number (little-endian)
++                "07 00 00 00"  # Frame_Size (little-endian)
++                "00 00 00 00 00 00 00"  # User_Data
++            )
++            # Zstandard frame
++            + zstd_compress(b"y" * 1024)
++        )
++
++        fp = BytesIO(data)
++        r = HTTPResponse(
++            fp, headers={"content-encoding": "zstd"}, preload_content=False
++        )
++        # Read the whole first frame.
++        assert r.read(1024) == b"x" * 1024
++        assert len(r._decoded_buffer) == 0
++        # Read the whole second frame in two reads.
++        assert r.read(512) == b"y" * 512
++        assert len(r._decoded_buffer) == 0
++        assert r.read(512) == b"y" * 512
++        assert len(r._decoded_buffer) == 0
++        # Ensure no more data is left.
++        assert r.read() == b""
++        assert len(r._decoded_buffer) == 0
+ 
+     @onlyZstd()
+     def test_chunked_decoding_zstd(self) -> None:
+@@ -535,6 +631,169 @@ class TestResponse:
+             decoded_data += part
+         assert decoded_data == data
+ 
++    _test_compressor_params: list[
++        tuple[str, tuple[str, typing.Callable[[bytes], bytes]] | None]
++    ] = [
++        ("deflate1", ("deflate", zlib.compress)),
++        ("deflate2", ("deflate", deflate2_compress)),
++        ("gzip", ("gzip", gzip.compress)),
++    ]
++    if _brotli_gte_1_2_0_available:
++        _test_compressor_params.append(("brotli", ("br", brotli.compress)))
++    else:
++        _test_compressor_params.append(("brotli", None))
++    if _zstd_available:
++        _test_compressor_params.append(("zstd", ("zstd", zstd_compress)))
++    else:
++        _test_compressor_params.append(("zstd", None))
++
++    @pytest.mark.parametrize("read_method", ("read", "read1"))
++    @pytest.mark.parametrize(
++        "data",
++        [d[1] for d in _test_compressor_params],
++        ids=[d[0] for d in _test_compressor_params],
++    )
++    def test_read_with_all_data_already_in_decompressor(
++        self,
++        request: pytest.FixtureRequest,
++        read_method: str,
++        data: tuple[str, typing.Callable[[bytes], bytes]] | None,
++    ) -> None:
++        if data is None:
++            pytest.skip(f"Proper {request.node.callspec.id} decoder is not available")
++        original_data = b"bar" * 1000
++        name, compress_func = data
++        compressed_data = compress_func(original_data)
++        fp = mock.Mock(read=mock.Mock(return_value=b""))
++        r = HTTPResponse(fp, headers={"content-encoding": name}, preload_content=False)
++        # Put all data in the decompressor's buffer.
++        r._init_decoder()
++        assert r._decoder is not None  # for mypy
++        decoded = r._decoder.decompress(compressed_data, max_length=0)
++        if name == "br":
++            # It's known that some Brotli libraries do not respect
++            # `max_length`.
++            r._decoded_buffer.put(decoded)
++        else:
++            assert decoded == b""
++        # Read the data via `HTTPResponse`.
++        read = getattr(r, read_method)
++        assert read(0) == b""
++        assert read(2500) == original_data[:2500]
++        assert read(500) == original_data[2500:]
++        assert read(0) == b""
++        assert read() == b""
++
++    @pytest.mark.parametrize(
++        "delta",
++        (
++            0,  # First read from socket returns all compressed data.
++            -1,  # First read from socket returns all but one byte of compressed data.
++        ),
++    )
++    @pytest.mark.parametrize("read_method", ("read", "read1"))
++    @pytest.mark.parametrize(
++        "data",
++        [d[1] for d in _test_compressor_params],
++        ids=[d[0] for d in _test_compressor_params],
++    )
++    def test_decode_with_max_length_close_to_compressed_data_size(
++        self,
++        request: pytest.FixtureRequest,
++        delta: int,
++        read_method: str,
++        data: tuple[str, typing.Callable[[bytes], bytes]] | None,
++    ) -> None:
++        """
++        Test decoding when the first read from the socket returns all or
++        almost all the compressed data, but then it has to be
++        decompressed in a couple of read calls.
++        """
++        if data is None:
++            pytest.skip(f"Proper {request.node.callspec.id} decoder is not available")
++
++        original_data = b"foo" * 1000
++        name, compress_func = data
++        compressed_data = compress_func(original_data)
++        fp = BytesIO(compressed_data)
++        r = HTTPResponse(fp, headers={"content-encoding": name}, preload_content=False)
++        initial_limit = len(compressed_data) + delta
++        read = getattr(r, read_method)
++        initial_chunk = read(amt=initial_limit, decode_content=True)
++        assert len(initial_chunk) == initial_limit
++        assert (
++            len(read(amt=len(original_data), decode_content=True))
++            == len(original_data) - initial_limit
++        )
++
++    # Prepare 50 MB of compressed data outside of the test measuring
++    # memory usage.
++    _test_memory_usage_decode_with_max_length_params: list[
++        tuple[str, tuple[str, bytes] | None]
++    ] = [
++        (
++            params[0],
++            (params[1][0], params[1][1](b"A" * (50 * 2**20))) if params[1] else None,
++        )
++        for params in _test_compressor_params
++    ]
++
++    @pytest.mark.parametrize(
++        "data",
++        [d[1] for d in _test_memory_usage_decode_with_max_length_params],
++        ids=[d[0] for d in _test_memory_usage_decode_with_max_length_params],
++    )
++    @pytest.mark.parametrize("read_method", ("read", "read1", "read_chunked", "stream"))
++    # Decoders consume different amounts of memory during decompression.
++    # We set the 10 MB limit to ensure that the whole decompressed data
++    # is not stored unnecessarily.
++    #
++    # FYI, the following consumption was observed for the test with
++    # `read` on CPython 3.14.0:
++    #   - deflate: 2.3 MiB
++    #   - deflate2: 2.1 MiB
++    #   - gzip: 2.1 MiB
++    #   - brotli:
++    #     - brotli v1.2.0: 9 MiB
++    #     - brotlicffi v1.2.0.0: 6 MiB
++    #     - brotlipy v0.7.0: 105.8 MiB
++    #   - zstd: 4.5 MiB
++    @pytest.mark.limit_memory("10 MB", current_thread_only=True)
++    def test_memory_usage_decode_with_max_length(
++        self,
++        request: pytest.FixtureRequest,
++        read_method: str,
++        data: tuple[str, bytes] | None,
++    ) -> None:
++        if data is None:
++            pytest.skip(f"Proper {request.node.callspec.id} decoder is not available")
++
++        name, compressed_data = data
++        limit = 1024 * 1024  # 1 MiB
++        if read_method in ("read_chunked", "stream"):
++            httplib_r = httplib.HTTPResponse(MockSock)  # type: ignore[arg-type]
++            httplib_r.fp = MockChunkedEncodingResponse([compressed_data])  # type: ignore[assignment]
++            r = HTTPResponse(
++                httplib_r,
++                preload_content=False,
++                headers={"transfer-encoding": "chunked", "content-encoding": name},
++            )
++            next(getattr(r, read_method)(amt=limit, decode_content=True))
++        else:
++            fp = BytesIO(compressed_data)
++            r = HTTPResponse(
++                fp, headers={"content-encoding": name}, preload_content=False
++            )
++            getattr(r, read_method)(amt=limit, decode_content=True)
++
++        # Check that the internal decoded buffer is empty unless brotli
++        # is used.
++        # Google's brotli library does not fully respect the output
++        # buffer limit: https://github.com/google/brotli/issues/1396
++        # And unmaintained brotlipy cannot limit the output buffer size.
++        if name != "br" or brotli.__name__ == "brotlicffi":
++            assert len(r._decoded_buffer) == 0
++
+     def test_multi_decoding_deflate_deflate(self) -> None:
+         data = zlib.compress(zlib.compress(b"foo"))
+ 
diff --git a/meta/recipes-devtools/python/python3-urllib3_2.5.0.bb b/meta/recipes-devtools/python/python3-urllib3_2.5.0.bb
index c39e9676e8..dcdf45439a 100644
--- a/meta/recipes-devtools/python/python3-urllib3_2.5.0.bb
+++ b/meta/recipes-devtools/python/python3-urllib3_2.5.0.bb
@@ -9,6 +9,7 @@ inherit pypi python_hatchling
 
 SRC_URI += "\
     file://CVE-2025-66418.patch \
+    file://CVE-2025-66471.patch \
 "
 
 DEPENDS += "python3-hatch-vcs-native"

[OE-core][whinlatter 05/11] python3: upgrade 3.13.9 -> 3.13.11

[Yoann Congal]

From: Peter Marko <peter.marko@siemens.com>

Handles CVE-2025-6075 (in 3.13.10) and CVE-2025-12084 (in 3.13.11).

Release information:
* https://www.python.org/downloads/release/python-31310/
* Python 3.13.10 is the tenth maintenance release of 3.13, containing
  around 300 bugfixes, build improvements and documentation changes
  since 3.13.9.

* https://www.python.org/downloads/release/python-31311/
* Python 3.13.11 is the eleventh maintenance release of 3.13. This is
   an expedited release to fix the following regressions:
  * gh-142206: Exceptions in multiprocessing in running programs while
    upgrading Python.
  * gh-142218: Segmentation faults and assertion failures in
    insertdict.
  * gh-140797: Crash when using multiple capturing groups in re.Scanner
* And these security fixes:
  * gh-142145: Remove quadratic behavior in node ID cache clearing
    (CVE-2025-12084)
  * gh-119451: Fix a potential denial of service in http.client
  * gh-119452: Fix a potential virtual memory allocation denial of
    service in http.server

Signed-off-by: Peter Marko <peter.marko@siemens.com>
---
 .../python/{python3_3.13.9.bb => python3_3.13.11.bb}            | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-devtools/python/{python3_3.13.9.bb => python3_3.13.11.bb} (99%)

diff --git a/meta/recipes-devtools/python/python3_3.13.9.bb b/meta/recipes-devtools/python/python3_3.13.11.bb
similarity index 99%
rename from meta/recipes-devtools/python/python3_3.13.9.bb
rename to meta/recipes-devtools/python/python3_3.13.11.bb
index 2e114a6c5b..2fcfd4aba1 100644
--- a/meta/recipes-devtools/python/python3_3.13.9.bb
+++ b/meta/recipes-devtools/python/python3_3.13.11.bb
@@ -35,7 +35,7 @@ SRC_URI:append:class-native = " \
            file://0001-Lib-sysconfig.py-use-prefix-value-from-build-configu.patch \
            "
 
-SRC_URI[sha256sum] = "ed5ef34cda36cfa2f3a340f07cac7e7814f91c7f3c411f6d3562323a866c5c66"
+SRC_URI[sha256sum] = "16ede7bb7cdbfa895d11b0642fa0e523f291e6487194d53cf6d3b338c3a17ea2"
 
 # exclude pre-releases for both python 2.x and 3.x
 UPSTREAM_CHECK_REGEX = "[Pp]ython-(?P<pver>\d+(\.\d+)+).tar"

[OE-core][whinlatter 06/11] libarchive: upgrade 3.8.3 -> 3.8.4

[Yoann Congal]

From: Peter Marko <peter.marko@siemens.com>

Handles CVE-2025-60753.

Release Notes [1]:
Libarchive 3.8.4 is a bugfix release.
Notable bugxies:
* bsdtar: Fix zero-length pattern issue (#2787)
* lib: Fix regression introduced in libarchive 3.8.2 when walking enterable but unreadable directories (#2797)
Full Changelog: [2]

[1] https://github.com/libarchive/libarchive/releases/tag/v3.8.4
[2] https://github.com/libarchive/libarchive/compare/v3.8.3...v3.8.4

(From OE-Core rev: 5479a5e6bcdebd2c5c6f1cbbe039243cf9fbc6b0)

Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
 .../libarchive/{libarchive_3.8.3.bb => libarchive_3.8.4.bb}     | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-extended/libarchive/{libarchive_3.8.3.bb => libarchive_3.8.4.bb} (96%)

diff --git a/meta/recipes-extended/libarchive/libarchive_3.8.3.bb b/meta/recipes-extended/libarchive/libarchive_3.8.4.bb
similarity index 96%
rename from meta/recipes-extended/libarchive/libarchive_3.8.3.bb
rename to meta/recipes-extended/libarchive/libarchive_3.8.4.bb
index e3706ba3bb..e89638f5c6 100644
--- a/meta/recipes-extended/libarchive/libarchive_3.8.3.bb
+++ b/meta/recipes-extended/libarchive/libarchive_3.8.4.bb
@@ -32,7 +32,7 @@ EXTRA_OECONF += "--enable-largefile --without-iconv"
 SRC_URI = "https://libarchive.org/downloads/libarchive-${PV}.tar.gz"
 UPSTREAM_CHECK_URI = "https://www.libarchive.org/"
 
-SRC_URI[sha256sum] = "a290c2d82bce7b806d1e5309558a7bd0ef39067a868f4622a0e32e71a4de8cb6"
+SRC_URI[sha256sum] = "b2c75b132a0ec43274d2867221befcb425034cd038e465afbfad09911abb1abb"
 
 inherit autotools update-alternatives pkgconfig
 

[OE-core][whinlatter 07/11] glib-2.0: upgrade 2.86.1 -> 2.86.3

[Yoann Congal]

From: Alexander Kanavin <alex@linutronix.de>

Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

(From OE-Core rev: 2041beac5c9cf081c5c23220c6fb259381611111)

Handles CVE-2025-13601, CVE-2025-14087 and CVE-2025-14512.

Signed-off-by: Peter Marko <peter.marko@siemens.com>
---
 ...001-Do-not-write-bindir-into-pkg-config-files.patch | 10 +++++-----
 .../files/0001-Fix-DATADIRNAME-on-uclibc-Linux.patch   |  2 +-
 ...1-Install-gio-querymodules-as-libexec_PROGRAM.patch |  6 +++---
 ...the-warning-about-deprecated-paths-in-schemas.patch |  2 +-
 ...ts-resources.c-comment-out-a-build-host-only-.patch |  2 +-
 .../0001-meson-Run-atomics-test-on-clang-as-well.patch |  6 +++---
 ...uild-do-not-enable-pidfd-features-on-native-g.patch |  6 +++---
 ...o-not-hardcode-python-path-into-various-tools.patch |  2 +-
 .../recipes-core/glib-2.0/files/relocate-modules.patch |  8 ++++----
 meta/recipes-core/glib-2.0/files/skip-timeout.patch    |  2 +-
 ....0-initial_2.86.1.bb => glib-2.0-initial_2.86.3.bb} |  0
 .../{glib-2.0_2.86.1.bb => glib-2.0_2.86.3.bb}         |  0
 meta/recipes-core/glib-2.0/glib.inc                    |  2 +-
 13 files changed, 24 insertions(+), 24 deletions(-)
 rename meta/recipes-core/glib-2.0/{glib-2.0-initial_2.86.1.bb => glib-2.0-initial_2.86.3.bb} (100%)
 rename meta/recipes-core/glib-2.0/{glib-2.0_2.86.1.bb => glib-2.0_2.86.3.bb} (100%)

diff --git a/meta/recipes-core/glib-2.0/files/0001-Do-not-write-bindir-into-pkg-config-files.patch b/meta/recipes-core/glib-2.0/files/0001-Do-not-write-bindir-into-pkg-config-files.patch
index c394ab3277..06841ddfb8 100644
--- a/meta/recipes-core/glib-2.0/files/0001-Do-not-write-bindir-into-pkg-config-files.patch
+++ b/meta/recipes-core/glib-2.0/files/0001-Do-not-write-bindir-into-pkg-config-files.patch
@@ -1,4 +1,4 @@
-From 8981db5d775e04b72fb68b6a4553c87fdaedee65 Mon Sep 17 00:00:00 2001
+From 6fe3965383d94b3030e85ab899955858710fec5c Mon Sep 17 00:00:00 2001
 From: Alexander Kanavin <alex.kanavin@gmail.com>
 Date: Fri, 15 Feb 2019 11:17:27 +0100
 Subject: [PATCH] Do not prefix executables with $bindir in pkg-config files
@@ -15,10 +15,10 @@ Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
  2 files changed, 13 insertions(+), 11 deletions(-)
 
 diff --git a/gio/meson.build b/gio/meson.build
-index 5d91b89..1a8da12 100644
+index 2f8f188..57c48d2 100644
 --- a/gio/meson.build
 +++ b/gio/meson.build
-@@ -901,17 +901,18 @@ libgio_dep = declare_dependency(link_with : libgio,
+@@ -912,17 +912,18 @@ libgio_dep = declare_dependency(link_with : libgio,
  pkg.generate(libgio,
    requires : ['glib-2.0', 'gobject-2.0'],
    variables : [
@@ -46,10 +46,10 @@ index 5d91b89..1a8da12 100644
    uninstalled_variables : [
      'gio=${prefix}/gio/gio',
 diff --git a/glib/meson.build b/glib/meson.build
-index 837960d..97d4af0 100644
+index 209bcbf..a86cfd3 100644
 --- a/glib/meson.build
 +++ b/glib/meson.build
-@@ -443,9 +443,10 @@ pkg.generate(libglib,
+@@ -464,9 +464,10 @@ pkg.generate(libglib,
    subdirs : ['glib-2.0'],
    extra_cflags : ['-I${libdir}/glib-2.0/include'] + win32_cflags,
    variables : [
diff --git a/meta/recipes-core/glib-2.0/files/0001-Fix-DATADIRNAME-on-uclibc-Linux.patch b/meta/recipes-core/glib-2.0/files/0001-Fix-DATADIRNAME-on-uclibc-Linux.patch
index 19fffbdc5f..b91624da8b 100644
--- a/meta/recipes-core/glib-2.0/files/0001-Fix-DATADIRNAME-on-uclibc-Linux.patch
+++ b/meta/recipes-core/glib-2.0/files/0001-Fix-DATADIRNAME-on-uclibc-Linux.patch
@@ -1,4 +1,4 @@
-From 48bfc87e9f757cf65ad967520860bfd7526c36f2 Mon Sep 17 00:00:00 2001
+From 966c58aae35f9e2bcef5238e0331a119e0e51abd Mon Sep 17 00:00:00 2001
 From: Khem Raj <raj.khem@gmail.com>
 Date: Sat, 15 Mar 2014 22:42:29 -0700
 Subject: [PATCH] Fix DATADIRNAME on uclibc/Linux
diff --git a/meta/recipes-core/glib-2.0/files/0001-Install-gio-querymodules-as-libexec_PROGRAM.patch b/meta/recipes-core/glib-2.0/files/0001-Install-gio-querymodules-as-libexec_PROGRAM.patch
index 89ba10ff6d..2ebf01b672 100644
--- a/meta/recipes-core/glib-2.0/files/0001-Install-gio-querymodules-as-libexec_PROGRAM.patch
+++ b/meta/recipes-core/glib-2.0/files/0001-Install-gio-querymodules-as-libexec_PROGRAM.patch
@@ -1,4 +1,4 @@
-From b8dcbf03b315d31759176e9d4fd389e8fda6ffcd Mon Sep 17 00:00:00 2001
+From 0de3a3a791ca32f2330eb3a8ad9da0fe6dce950c Mon Sep 17 00:00:00 2001
 From: Jussi Kukkonen <jussi.kukkonen@intel.com>
 Date: Tue, 22 Mar 2016 15:14:58 +0200
 Subject: [PATCH] Install gio-querymodules as libexec_PROGRAM
@@ -13,10 +13,10 @@ Upstream-Status: Inappropriate [OE specific]
  1 file changed, 1 insertion(+)
 
 diff --git a/gio/meson.build b/gio/meson.build
-index 854b95a..5d91b89 100644
+index 39256d3..2f8f188 100644
 --- a/gio/meson.build
 +++ b/gio/meson.build
-@@ -1038,6 +1038,7 @@ gio_querymodules = executable('gio-querymodules', 'gio-querymodules.c', 'giomodu
+@@ -1049,6 +1049,7 @@ gio_querymodules = executable('gio-querymodules', 'gio-querymodules.c', 'giomodu
    c_args : gio_c_args,
    # intl.lib is not compatible with SAFESEH
    link_args : noseh_link_args,
diff --git a/meta/recipes-core/glib-2.0/files/0001-Remove-the-warning-about-deprecated-paths-in-schemas.patch b/meta/recipes-core/glib-2.0/files/0001-Remove-the-warning-about-deprecated-paths-in-schemas.patch
index ebdf957272..d6dd66357a 100644
--- a/meta/recipes-core/glib-2.0/files/0001-Remove-the-warning-about-deprecated-paths-in-schemas.patch
+++ b/meta/recipes-core/glib-2.0/files/0001-Remove-the-warning-about-deprecated-paths-in-schemas.patch
@@ -1,4 +1,4 @@
-From bdb2772d672e95584585e902689936559c5db05d Mon Sep 17 00:00:00 2001
+From b829f3205e4d8390f02eaa8e7a7bf85e51cbb7ed Mon Sep 17 00:00:00 2001
 From: Alexander Kanavin <alex.kanavin@gmail.com>
 Date: Fri, 12 Jun 2015 17:08:46 +0300
 Subject: [PATCH] Remove the warning about deprecated paths in schemas
diff --git a/meta/recipes-core/glib-2.0/files/0001-gio-tests-resources.c-comment-out-a-build-host-only-.patch b/meta/recipes-core/glib-2.0/files/0001-gio-tests-resources.c-comment-out-a-build-host-only-.patch
index 771b03e66d..7a2fc0b7ef 100644
--- a/meta/recipes-core/glib-2.0/files/0001-gio-tests-resources.c-comment-out-a-build-host-only-.patch
+++ b/meta/recipes-core/glib-2.0/files/0001-gio-tests-resources.c-comment-out-a-build-host-only-.patch
@@ -1,4 +1,4 @@
-From 8cb75d3bc368ee108a4b14bc57a92bd0c0b2e10e Mon Sep 17 00:00:00 2001
+From 912e674bb0a3b51dabaa58da1834491ef94e6a2a Mon Sep 17 00:00:00 2001
 From: Alexander Kanavin <alex.kanavin@gmail.com>
 Date: Wed, 8 Jan 2020 18:22:46 +0100
 Subject: [PATCH] gio/tests/resources.c: comment out a build host-only test
diff --git a/meta/recipes-core/glib-2.0/files/0001-meson-Run-atomics-test-on-clang-as-well.patch b/meta/recipes-core/glib-2.0/files/0001-meson-Run-atomics-test-on-clang-as-well.patch
index 5ad2a0375b..e4b0d6be79 100644
--- a/meta/recipes-core/glib-2.0/files/0001-meson-Run-atomics-test-on-clang-as-well.patch
+++ b/meta/recipes-core/glib-2.0/files/0001-meson-Run-atomics-test-on-clang-as-well.patch
@@ -1,4 +1,4 @@
-From 502984fe340a76c92e2c04235f43fdcb47728806 Mon Sep 17 00:00:00 2001
+From 26ddae02d7677bcff7c3933ee856d34df41b548f Mon Sep 17 00:00:00 2001
 From: Khem Raj <raj.khem@gmail.com>
 Date: Sat, 12 Oct 2019 17:46:26 -0700
 Subject: [PATCH] meson: Run atomics test on clang as well
@@ -14,10 +14,10 @@ Signed-off-by: Khem Raj <raj.khem@gmail.com>
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/meson.build b/meson.build
-index a8bcadc..041b68e 100644
+index dab1d61..cc3a5ed 100644
 --- a/meson.build
 +++ b/meson.build
-@@ -2077,7 +2077,7 @@ atomicdefine = '''
+@@ -2092,7 +2092,7 @@ atomicdefine = '''
  # We know that we can always use real ("lock free") atomic operations with MSVC
  if cc.get_id() == 'msvc' or cc.get_id() == 'clang-cl' or cc.links(atomictest, name : 'atomic ops')
    have_atomic_lock_free = true
diff --git a/meta/recipes-core/glib-2.0/files/0001-meson.build-do-not-enable-pidfd-features-on-native-g.patch b/meta/recipes-core/glib-2.0/files/0001-meson.build-do-not-enable-pidfd-features-on-native-g.patch
index aa098da379..712ae25b27 100644
--- a/meta/recipes-core/glib-2.0/files/0001-meson.build-do-not-enable-pidfd-features-on-native-g.patch
+++ b/meta/recipes-core/glib-2.0/files/0001-meson.build-do-not-enable-pidfd-features-on-native-g.patch
@@ -1,4 +1,4 @@
-From d5e566c45a9ab4d7e51104ab176e6eb5f705f91d Mon Sep 17 00:00:00 2001
+From c6cd3c0a66ae8f210185e0cb05b2172dc192ce9e Mon Sep 17 00:00:00 2001
 From: Alexander Kanavin <alex@linutronix.de>
 Date: Sat, 16 Sep 2023 22:28:27 +0200
 Subject: [PATCH] meson.build: do not enable pidfd features on native glib
@@ -14,10 +14,10 @@ Signed-off-by: Alexander Kanavin <alex@linutronix.de>
  1 file changed, 2 insertions(+), 1 deletion(-)
 
 diff --git a/meson.build b/meson.build
-index 041b68e..155bfd4 100644
+index cc3a5ed..58dd87a 100644
 --- a/meson.build
 +++ b/meson.build
-@@ -1075,7 +1075,8 @@ if cc.links('''#include <sys/syscall.h>
+@@ -1090,7 +1090,8 @@ if cc.links('''#include <sys/syscall.h>
                   waitid (P_PIDFD, 0, &child_info, WEXITED | WNOHANG);
                   return 0;
                 }''', name : 'pidfd_open(2) system call')
diff --git a/meta/recipes-core/glib-2.0/files/0010-Do-not-hardcode-python-path-into-various-tools.patch b/meta/recipes-core/glib-2.0/files/0010-Do-not-hardcode-python-path-into-various-tools.patch
index d26f944d51..8dbdf746b7 100644
--- a/meta/recipes-core/glib-2.0/files/0010-Do-not-hardcode-python-path-into-various-tools.patch
+++ b/meta/recipes-core/glib-2.0/files/0010-Do-not-hardcode-python-path-into-various-tools.patch
@@ -1,4 +1,4 @@
-From 211927d2caa4a81e1131c2210e1db838104a1fb9 Mon Sep 17 00:00:00 2001
+From 40e40230e6a3c52b79c6f92e8c060bd4d93f0374 Mon Sep 17 00:00:00 2001
 From: Alexander Kanavin <alex.kanavin@gmail.com>
 Date: Tue, 3 Oct 2017 10:45:55 +0300
 Subject: [PATCH] Do not hardcode python path into various tools
diff --git a/meta/recipes-core/glib-2.0/files/relocate-modules.patch b/meta/recipes-core/glib-2.0/files/relocate-modules.patch
index ddf464526c..09de155d08 100644
--- a/meta/recipes-core/glib-2.0/files/relocate-modules.patch
+++ b/meta/recipes-core/glib-2.0/files/relocate-modules.patch
@@ -1,4 +1,4 @@
-From 456bac53f19d3094aa2007054c87d86c9d65b423 Mon Sep 17 00:00:00 2001
+From 14bbc77bc465b42454112bc6a33264c2c3e013e5 Mon Sep 17 00:00:00 2001
 From: Ross Burton <ross.burton@intel.com>
 Date: Fri, 11 Mar 2016 15:35:55 +0000
 Subject: [PATCH] glib-2.0: relocate the GIO module directory for native builds
@@ -18,10 +18,10 @@ Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
  1 file changed, 7 deletions(-)
 
 diff --git a/gio/giomodule.c b/gio/giomodule.c
-index 76c2028..6deba7c 100644
+index 38761e4..afa7878 100644
 --- a/gio/giomodule.c
 +++ b/gio/giomodule.c
-@@ -1260,11 +1260,6 @@ get_gio_module_dir (void)
+@@ -1272,11 +1272,6 @@ get_gio_module_dir (void)
        g_free (install_dir);
  #else
        module_dir = g_strdup (GIO_MODULE_DIR);
@@ -33,7 +33,7 @@ index 76c2028..6deba7c 100644
  #include <dlfcn.h>
        {
          g_autofree gchar *path = NULL;
-@@ -1283,8 +1278,6 @@ get_gio_module_dir (void)
+@@ -1295,8 +1290,6 @@ get_gio_module_dir (void)
                }
            }
        }
diff --git a/meta/recipes-core/glib-2.0/files/skip-timeout.patch b/meta/recipes-core/glib-2.0/files/skip-timeout.patch
index 138e970553..8ef140d0d7 100644
--- a/meta/recipes-core/glib-2.0/files/skip-timeout.patch
+++ b/meta/recipes-core/glib-2.0/files/skip-timeout.patch
@@ -1,4 +1,4 @@
-From 51bfcab0b60bd57f4d3463c479fdf47e645cd6fe Mon Sep 17 00:00:00 2001
+From f77b9dd72dd0103c7a28dd7e1cdf6e316ecbf030 Mon Sep 17 00:00:00 2001
 From: Ross Burton <ross.burton@arm.com>
 Date: Thu, 28 Mar 2024 16:27:09 +0000
 Subject: [PATCH] Skip /timeout/rounding test
diff --git a/meta/recipes-core/glib-2.0/glib-2.0-initial_2.86.1.bb b/meta/recipes-core/glib-2.0/glib-2.0-initial_2.86.3.bb
similarity index 100%
rename from meta/recipes-core/glib-2.0/glib-2.0-initial_2.86.1.bb
rename to meta/recipes-core/glib-2.0/glib-2.0-initial_2.86.3.bb
diff --git a/meta/recipes-core/glib-2.0/glib-2.0_2.86.1.bb b/meta/recipes-core/glib-2.0/glib-2.0_2.86.3.bb
similarity index 100%
rename from meta/recipes-core/glib-2.0/glib-2.0_2.86.1.bb
rename to meta/recipes-core/glib-2.0/glib-2.0_2.86.3.bb
diff --git a/meta/recipes-core/glib-2.0/glib.inc b/meta/recipes-core/glib-2.0/glib.inc
index 5909851896..bd87d9c601 100644
--- a/meta/recipes-core/glib-2.0/glib.inc
+++ b/meta/recipes-core/glib-2.0/glib.inc
@@ -236,7 +236,7 @@ SRC_URI:append:class-native = " file://relocate-modules.patch \
                                 file://0001-meson.build-do-not-enable-pidfd-features-on-native-g.patch \
                               "
 
-SRC_URI[archive.sha256sum] = "119d1708ca022556d6d2989ee90ad1b82bd9c0d1667e066944a6d0020e2d5e57"
+SRC_URI[archive.sha256sum] = "b3211d8d34b9df5dca05787ef0ad5d7ca75dec998b970e1aab0001d229977c65"
 
 # Find any meson cross files in FILESPATH that are relevant for the current
 # build (using siteinfo) and add them to EXTRA_OEMESON.

[OE-core][whinlatter 08/11] libpng: upgrade 1.6.51 -> 1.6.52

[Yoann Congal]

From: Peter Marko <peter.marko@siemens.com>

Handles CVE-2025-66293

>From Release Notes [1]:
  Fixed CVE-2025-66293 (high severity):
    Out-of-bounds read in `png_image_read_composite`.
    (Reported by flyfish101 <flyfish101@users.noreply.github.com>.)
  Fixed the Paeth filter handling in the RISC-V RVV implementation.
    (Reported by Filip Wasil; fixed by Liang Junzhao.)
  Improved the performance of the RISC-V RVV implementation.
    (Contributed by Liang Junzhao.)
  Added allocation failure fuzzing to oss-fuzz.
    (Contributed by Philippe Antoine.)

[1] https://github.com/pnggroup/libpng/blob/v1.6.52/CHANGES#L6307-L6316

(From OE-Core rev: 424c8aba2a52f464b2a652f56770437bdd08bf9e)

Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
 .../libpng/{libpng_1.6.51.bb => libpng_1.6.52.bb}               | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-multimedia/libpng/{libpng_1.6.51.bb => libpng_1.6.52.bb} (97%)

diff --git a/meta/recipes-multimedia/libpng/libpng_1.6.51.bb b/meta/recipes-multimedia/libpng/libpng_1.6.52.bb
similarity index 97%
rename from meta/recipes-multimedia/libpng/libpng_1.6.51.bb
rename to meta/recipes-multimedia/libpng/libpng_1.6.52.bb
index e499f61ff4..fba6e77b1c 100644
--- a/meta/recipes-multimedia/libpng/libpng_1.6.51.bb
+++ b/meta/recipes-multimedia/libpng/libpng_1.6.52.bb
@@ -14,7 +14,7 @@ SRC_URI = "${SOURCEFORGE_MIRROR}/${BPN}/${BPN}${LIBV}/${BP}.tar.xz \
            file://run-ptest \
 "
 
-SRC_URI[sha256sum] = "a050a892d3b4a7bb010c3a95c7301e49656d72a64f1fc709a90b8aded192bed2"
+SRC_URI[sha256sum] = "36bd726228ec93a3b6c22fdb49e94a67b16f2fe9b39b78b7cb65772966661ccc"
 
 MIRRORS += "${SOURCEFORGE_MIRROR}/project/${BPN}/${BPN}${LIBV}/ ${SOURCEFORGE_MIRROR}/project/${BPN}/${BPN}${LIBV}/older-releases/"
 

[OE-core][whinlatter 09/11] libpcap: upgrade 1.10.5 -> 1.10.6

[Yoann Congal]

From: Peter Marko <peter.marko@siemens.com>

Solves CVE-2025-11961 and CVE-2025-11964.

Signed-off-by: Peter Marko <peter.marko@siemens.com>
---
 .../libpcap/{libpcap_1.10.5.bb => libpcap_1.10.6.bb}            | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-connectivity/libpcap/{libpcap_1.10.5.bb => libpcap_1.10.6.bb} (95%)

diff --git a/meta/recipes-connectivity/libpcap/libpcap_1.10.5.bb b/meta/recipes-connectivity/libpcap/libpcap_1.10.6.bb
similarity index 95%
rename from meta/recipes-connectivity/libpcap/libpcap_1.10.5.bb
rename to meta/recipes-connectivity/libpcap/libpcap_1.10.6.bb
index 7ad52acd06..1b10001035 100644
--- a/meta/recipes-connectivity/libpcap/libpcap_1.10.5.bb
+++ b/meta/recipes-connectivity/libpcap/libpcap_1.10.6.bb
@@ -11,7 +11,7 @@ LIC_FILES_CHKSUM = "file://LICENSE;md5=5eb289217c160e2920d2e35bddc36453 \
 DEPENDS = "flex-native bison-native"
 
 SRC_URI = "https://www.tcpdump.org/release/${BP}.tar.xz"
-SRC_URI[sha256sum] = "84fa89ac6d303028c1c5b754abff77224f45eca0a94eb1a34ff0aa9ceece3925"
+SRC_URI[sha256sum] = "ec97d1206bdd19cb6bdd043eaa9f0037aa732262ec68e070fd7c7b5f834d5dfc"
 
 inherit autotools binconfig-disabled pkgconfig
 

[OE-core][whinlatter 10/11] Revert "populate_sdk_ext: keep SDK_TARGETS so SPDX/SBOM tasks remain in locked sigs"

[Yoann Congal]

From: Yoann Congal <yoann.congal@smile.fr>

This reverts commit 9964fa3da2fa1e7243fba1a826e59f7bb1813706.
This commit was not in master before landing in whinlatter.

Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
---
 meta/classes-recipe/populate_sdk_ext.bbclass | 9 ---------
 1 file changed, 9 deletions(-)

diff --git a/meta/classes-recipe/populate_sdk_ext.bbclass b/meta/classes-recipe/populate_sdk_ext.bbclass
index 2838ca1a03..2859320ddf 100644
--- a/meta/classes-recipe/populate_sdk_ext.bbclass
+++ b/meta/classes-recipe/populate_sdk_ext.bbclass
@@ -460,15 +460,6 @@ def prepare_locked_cache(d, baseoutpath, derivative, conf_initpath):
 
     # Filter the locked signatures file to just the sstate tasks we are interested in
     excluded_targets = get_sdk_install_targets(d, images_only=True)
-    sdk_targets = d.getVar('SDK_TARGETS')
-    ext_sdk_target_set = set(multilib_pkg_extend(d, sdk_targets).split())
-    excluded_set = set(excluded_targets.split())
-
-    # Ensure SDK_TARGETS and their image SPDX/SBOM tasks are included in the locked signatures,
-    # as they are required during eSDK installation.
-    filtered_excluded_set = excluded_set - ext_sdk_target_set
-    excluded_targets = ' '.join(filtered_excluded_set)
-
     sigfile = d.getVar('WORKDIR') + '/locked-sigs.inc'
     lockedsigs_pruned = baseoutpath + '/conf/locked-sigs.inc'
     #nativesdk-only sigfile to merge into locked-sigs.inc

[OE-core][whinlatter 11/11] Revert "create-spdx-image-3.0: Image SPDX/SBOM tasks are retained for eSDK installation"

[Yoann Congal]

From: Yoann Congal <yoann.congal@smile.fr>

This reverts commit 3f57280caa7918f10e4e9685ad87a3128d4e9f0f.
This commit was not in master before landing in whinlatter.

Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
---
 meta/classes-recipe/create-spdx-image-3.0.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes-recipe/create-spdx-image-3.0.bbclass b/meta/classes-recipe/create-spdx-image-3.0.bbclass
index f070b7e697..636ab14eb0 100644
--- a/meta/classes-recipe/create-spdx-image-3.0.bbclass
+++ b/meta/classes-recipe/create-spdx-image-3.0.bbclass
@@ -69,7 +69,7 @@ python do_create_image_sbom_spdx() {
     import oe.spdx30_tasks
     oe.spdx30_tasks.create_image_sbom_spdx(d)
 }
-addtask do_create_image_sbom_spdx after do_create_rootfs_spdx do_create_image_spdx before do_build do_sdk_depends
+addtask do_create_image_sbom_spdx after do_create_rootfs_spdx do_create_image_spdx before do_build
 SSTATETASKS += "do_create_image_sbom_spdx"
 SSTATE_SKIP_CREATION:task-create-image-sbom = "1"
 do_create_image_sbom_spdx[sstate-inputdirs] = "${SPDXIMAGEDEPLOYDIR}"

Re: [OE-core][whinlatter 04/11] python3-urllib3: patch CVE-2025-66471

[Paul Barker]

[-- Attachment #1: Type: text/plain, Size: 825 bytes --]

On Wed, 2026-01-07 at 09:08 +0100, Yoann Congal via
lists.openembedded.org wrote:
> From: Peter Marko <peter.marko@siemens.com>
> 
> Pick patch per [1].
> 
> [1] https://nvd.nist.gov/vuln/detail/CVE-2025-66471
> 
> Signed-off-by: Peter Marko <peter.marko@siemens.com>
> ---
>  .../python3-urllib3/CVE-2025-66471.patch      | 930 ++++++++++++++++++
>  .../python/python3-urllib3_2.5.0.bb           |   1 +
>  2 files changed, 931 insertions(+)
>  create mode 100644 meta/recipes-devtools/python/python3-urllib3/CVE-2025-66471.patch

This seems like a very large patch for a CVE issue. The changelog entry
in the patch also says that the API of urllib3.response.ContentDecoder
is changed.

We should look for a narrower fix, and only take this if there is no
other option.

Thanks,

-- 
Paul Barker


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

RE: [OE-core][whinlatter 04/11] python3-urllib3: patch

[Marko, Peter]

> -----Original Message-----
> From: Paul Barker <paul@pbarker.dev>
> Sent: Wednesday, January 7, 2026 12:49
> To: yoann.congal@smile.fr; openembedded-core@lists.openembedded.org;
> Marko, Peter (FT D EU SK BFS1) <Peter.Marko@siemens.com>
> Subject: Re: [OE-core][whinlatter 04/11] python3-urllib3: patch
> 
> On Wed, 2026-01-07 at 09:08 +0100, Yoann Congal via
> lists.openembedded.org wrote:
> > From: Peter Marko <peter.marko@siemens.com>
> >
> > Pick patch per [1].
> >
> > [1] https://nvd.nist.gov/vuln/detail/CVE-2025-66471
> >
> > Signed-off-by: Peter Marko <peter.marko@siemens.com>
> > ---
> >  .../python3-urllib3/CVE-2025-66471.patch      | 930 ++++++++++++++++++
> >  .../python/python3-urllib3_2.5.0.bb           |   1 +
> >  2 files changed, 931 insertions(+)
> >  create mode 100644 meta/recipes-devtools/python/python3-urllib3/CVE-2025-
> 66471.patch
> 
> This seems like a very large patch for a CVE issue. The changelog entry
> in the patch also says that the API of urllib3.response.ContentDecoder
> is changed.
> 
> We should look for a narrower fix, and only take this if there is no
> other option.

I originally didn't want to patch this CVE due to this reason (and didn't patch it in kirkstone).
But since this has landed in scarthgap, I decided for the same in whinlatter for consistency.
Should we revert it from scartghap?

Peter

> 
> Thanks,
> 
> --
> Paul Barker

Re: [OE-core][whinlatter 04/11] python3-urllib3: patch

[Paul Barker]

[-- Attachment #1: Type: text/plain, Size: 2109 bytes --]

On Wed, 2026-01-07 at 12:19 +0000, Marko, Peter wrote:
> 
> > -----Original Message-----
> > From: Paul Barker <paul@pbarker.dev>
> > Sent: Wednesday, January 7, 2026 12:49
> > To: yoann.congal@smile.fr; openembedded-core@lists.openembedded.org;
> > Marko, Peter (FT D EU SK BFS1) <Peter.Marko@siemens.com>
> > Subject: Re: [OE-core][whinlatter 04/11] python3-urllib3: patch
> > 
> > On Wed, 2026-01-07 at 09:08 +0100, Yoann Congal via
> > lists.openembedded.org wrote:
> > > From: Peter Marko <peter.marko@siemens.com>
> > > 
> > > Pick patch per [1].
> > > 
> > > [1] https://nvd.nist.gov/vuln/detail/CVE-2025-66471
> > > 
> > > Signed-off-by: Peter Marko <peter.marko@siemens.com>
> > > ---
> > >  .../python3-urllib3/CVE-2025-66471.patch      | 930 ++++++++++++++++++
> > >  .../python/python3-urllib3_2.5.0.bb           |   1 +
> > >  2 files changed, 931 insertions(+)
> > >  create mode 100644 meta/recipes-devtools/python/python3-urllib3/CVE-2025-
> > 66471.patch
> > 
> > This seems like a very large patch for a CVE issue. The changelog entry
> > in the patch also says that the API of urllib3.response.ContentDecoder
> > is changed.
> > 
> > We should look for a narrower fix, and only take this if there is no
> > other option.
> 
> I originally didn't want to patch this CVE due to this reason (and didn't patch it in kirkstone).
> But since this has landed in scarthgap, I decided for the same in whinlatter for consistency.
> Should we revert it from scartghap?

I don't think we need to rush to a decision.

Have any other distros patched this CVE? I see it's still unpatched in
Debian [1], and Arch Linux is on v2.6.2 already [2]. Ubuntu has taken
the patch [3], we should check if they've modified it or directly taken
the upstream commit.

[1]: https://tracker.debian.org/pkg/python-urllib3
[2]: https://archlinux.org/packages/extra/any/python-urllib3/
[3]: https://launchpad.net/ubuntu/+source/python-urllib3/2.5.0-1ubuntu1

Jiaying Song: Any thoughts on this? You did the backport to scarthgap.

Best regards,

-- 
Paul Barker





[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [OE-core][whinlatter 04/11] python3-urllib3: patch

[Yoann Congal]

Le 07/01/2026 à 13:32, Paul Barker a écrit :
> On Wed, 2026-01-07 at 12:19 +0000, Marko, Peter wrote:
>>
>>> -----Original Message-----
>>> From: Paul Barker <paul@pbarker.dev>
>>> Sent: Wednesday, January 7, 2026 12:49
>>> To: yoann.congal@smile.fr; openembedded-core@lists.openembedded.org;
>>> Marko, Peter (FT D EU SK BFS1) <Peter.Marko@siemens.com>
>>> Subject: Re: [OE-core][whinlatter 04/11] python3-urllib3: patch
>>>
>>> On Wed, 2026-01-07 at 09:08 +0100, Yoann Congal via
>>> lists.openembedded.org wrote:
>>>> From: Peter Marko <peter.marko@siemens.com>
>>>>
>>>> Pick patch per [1].
>>>>
>>>> [1] https://nvd.nist.gov/vuln/detail/CVE-2025-66471
>>>>
>>>> Signed-off-by: Peter Marko <peter.marko@siemens.com>
>>>> ---
>>>>  .../python3-urllib3/CVE-2025-66471.patch      | 930 ++++++++++++++++++
>>>>  .../python/python3-urllib3_2.5.0.bb           |   1 +
>>>>  2 files changed, 931 insertions(+)
>>>>  create mode 100644 meta/recipes-devtools/python/python3-urllib3/CVE-2025-
>>> 66471.patch
>>>
>>> This seems like a very large patch for a CVE issue. The changelog entry
>>> in the patch also says that the API of urllib3.response.ContentDecoder
>>> is changed.
>>>
>>> We should look for a narrower fix, and only take this if there is no
>>> other option.
>>
>> I originally didn't want to patch this CVE due to this reason (and didn't patch it in kirkstone).
>> But since this has landed in scarthgap, I decided for the same in whinlatter for consistency.
>> Should we revert it from scartghap?
> 
> I don't think we need to rush to a decision.

On my side, I need to do the whinlatter 5.3.1 release build on Monday.
I propose to set this patch aside to not block the release and the other
patches.

For scarthgap, we can revert the current fix and add the "proper" fix
when we have it. I'd rather avoid a patched->applicable transition on a CVE.

Sounds good?

> 
> Have any other distros patched this CVE? I see it's still unpatched in
> Debian [1], and Arch Linux is on v2.6.2 already [2]. Ubuntu has taken
> the patch [3], we should check if they've modified it or directly taken
> the upstream commit.
> 
> [1]: https://tracker.debian.org/pkg/python-urllib3
> [2]: https://archlinux.org/packages/extra/any/python-urllib3/
> [3]: https://launchpad.net/ubuntu/+source/python-urllib3/2.5.0-1ubuntu1
> 
> Jiaying Song: Any thoughts on this? You did the backport to scarthgap.
> 
> Best regards,
> 

-- 
Yoann Congal
Smile ECS

Re: [OE-core][whinlatter 04/11] python3-urllib3: patch

[Paul Barker]

[-- Attachment #1: Type: text/plain, Size: 2303 bytes --]

On Wed, 2026-01-07 at 13:47 +0100, Yoann Congal wrote:
> 
> Le 07/01/2026 à 13:32, Paul Barker a écrit :
> > On Wed, 2026-01-07 at 12:19 +0000, Marko, Peter wrote:
> > > 
> > > > -----Original Message-----
> > > > From: Paul Barker <paul@pbarker.dev>
> > > > Sent: Wednesday, January 7, 2026 12:49
> > > > To: yoann.congal@smile.fr; openembedded-core@lists.openembedded.org;
> > > > Marko, Peter (FT D EU SK BFS1) <Peter.Marko@siemens.com>
> > > > Subject: Re: [OE-core][whinlatter 04/11] python3-urllib3: patch
> > > > 
> > > > On Wed, 2026-01-07 at 09:08 +0100, Yoann Congal via
> > > > lists.openembedded.org wrote:
> > > > > From: Peter Marko <peter.marko@siemens.com>
> > > > > 
> > > > > Pick patch per [1].
> > > > > 
> > > > > [1] https://nvd.nist.gov/vuln/detail/CVE-2025-66471
> > > > > 
> > > > > Signed-off-by: Peter Marko <peter.marko@siemens.com>
> > > > > ---
> > > > >  .../python3-urllib3/CVE-2025-66471.patch      | 930 ++++++++++++++++++
> > > > >  .../python/python3-urllib3_2.5.0.bb           |   1 +
> > > > >  2 files changed, 931 insertions(+)
> > > > >  create mode 100644 meta/recipes-devtools/python/python3-urllib3/CVE-2025-
> > > > 66471.patch
> > > > 
> > > > This seems like a very large patch for a CVE issue. The changelog entry
> > > > in the patch also says that the API of urllib3.response.ContentDecoder
> > > > is changed.
> > > > 
> > > > We should look for a narrower fix, and only take this if there is no
> > > > other option.
> > > 
> > > I originally didn't want to patch this CVE due to this reason (and didn't patch it in kirkstone).
> > > But since this has landed in scarthgap, I decided for the same in whinlatter for consistency.
> > > Should we revert it from scartghap?
> > 
> > I don't think we need to rush to a decision.
> 
> On my side, I need to do the whinlatter 5.3.1 release build on Monday.
> I propose to set this patch aside to not block the release and the other
> patches.

Agreed.

> For scarthgap, we can revert the current fix and add the "proper" fix
> when we have it. I'd rather avoid a patched->applicable transition on a CVE.

We don't need to do this immediately, let's take a little time to think
and see if others have any thoughts.

Best regards,

-- 
Paul Barker


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [OE-core][whinlatter 04/11] python3-urllib3: patch

[Yoann Congal]

[-- Attachment #1: Type: text/plain, Size: 3325 bytes --]

Le mer. 7 janv. 2026 à 15:05, Paul Barker <paul@pbarker.dev> a écrit :

> On Wed, 2026-01-07 at 13:47 +0100, Yoann Congal wrote:
> >
> > Le 07/01/2026 à 13:32, Paul Barker a écrit :
> > > On Wed, 2026-01-07 at 12:19 +0000, Marko, Peter wrote:
> > > >
> > > > > -----Original Message-----
> > > > > From: Paul Barker <paul@pbarker.dev>
> > > > > Sent: Wednesday, January 7, 2026 12:49
> > > > > To: yoann.congal@smile.fr;
> openembedded-core@lists.openembedded.org;
> > > > > Marko, Peter (FT D EU SK BFS1) <Peter.Marko@siemens.com>
> > > > > Subject: Re: [OE-core][whinlatter 04/11] python3-urllib3: patch
> > > > >
> > > > > On Wed, 2026-01-07 at 09:08 +0100, Yoann Congal via
> > > > > lists.openembedded.org wrote:
> > > > > > From: Peter Marko <peter.marko@siemens.com>
> > > > > >
> > > > > > Pick patch per [1].
> > > > > >
> > > > > > [1] https://nvd.nist.gov/vuln/detail/CVE-2025-66471
> > > > > >
> > > > > > Signed-off-by: Peter Marko <peter.marko@siemens.com>
> > > > > > ---
> > > > > >  .../python3-urllib3/CVE-2025-66471.patch      | 930
> ++++++++++++++++++
> > > > > >  .../python/python3-urllib3_2.5.0.bb           |   1 +
> > > > > >  2 files changed, 931 insertions(+)
> > > > > >  create mode 100644
> meta/recipes-devtools/python/python3-urllib3/CVE-2025-
> > > > > 66471.patch
> > > > >
> > > > > This seems like a very large patch for a CVE issue. The changelog
> entry
> > > > > in the patch also says that the API of
> urllib3.response.ContentDecoder
> > > > > is changed.
> > > > >
> > > > > We should look for a narrower fix, and only take this if there is
> no
> > > > > other option.
> > > >
> > > > I originally didn't want to patch this CVE due to this reason (and
> didn't patch it in kirkstone).
> > > > But since this has landed in scarthgap, I decided for the same in
> whinlatter for consistency.
> > > > Should we revert it from scartghap?
> > >
> > > I don't think we need to rush to a decision.
> >
> > On my side, I need to do the whinlatter 5.3.1 release build on Monday.
> > I propose to set this patch aside to not block the release and the other
> > patches.
>
> Agreed.
>
> > For scarthgap, we can revert the current fix and add the "proper" fix
> > when we have it. I'd rather avoid a patched->applicable transition on a
> CVE.
>
> We don't need to do this immediately, let's take a little time to think
> and see if others have any thoughts.
>

Ubuntu seem to have applied the patch with post-fixes :
https://git.launchpad.net/ubuntu/+source/python-urllib3/tree/debian/patches?h=ubuntu%2Fnoble-security
CVE-2025-66471.patch # the upstream patch
CVE-2025-66471-post1.patch  # Remove brotli version warning
CVE-2025-66471-fix1.patch # Revert fix for zstd
CVE-2025-66471-fix2.patch # Fix zstandard using unknown attribute

but also, has deem the fix too intrusive for most maintained releases:
https://ubuntu.com/security/CVE-2025-66471#status

Debian has not patched:
https://security-tracker.debian.org/tracker/CVE-2025-66471

> Intrusive to backport; requires update for src:brotli for effective fix
> The fix requires an updated src:brotli >= 1.2.0 for the fix to be
> effective,
> which adds the optional output_buffer_limit option to avoid these attacks.


-- 
Yoann Congal
Smile ECS

[-- Attachment #2: Type: text/html, Size: 5585 bytes --]

RE: [OE-core][whinlatter 04/11] python3-urllib3: patch

[Marko, Peter]

[-- Attachment #1: Type: text/plain, Size: 4122 bytes --]

Hello Yoann, Paul,

What shall we do with this patch?
Drop or take?

I also think that it’s intrusive, however having this fixed on older Yocto release and not fixed in newer is weird.
https://git.openembedded.org/openembedded-core/commit/?h=scarthgap&id=d9f52c5f86bcc4716e384fe5c01c03d386d60446

Peter


From: Yoann Congal <yoann.congal@smile.fr>
Sent: Friday, January 30, 2026 11:34
To: Paul Barker <paul@pbarker.dev>
Cc: Marko, Peter (FT D EU SK BFS1) <Peter.Marko@siemens.com>; openembedded-core@lists.openembedded.org; Jiaying Song <jiaying.song.cn@windriver.com>
Subject: Re: [OE-core][whinlatter 04/11] python3-urllib3: patch



Le mer. 7 janv. 2026 à 15:05, Paul Barker <paul@pbarker.dev<mailto:paul@pbarker.dev>> a écrit :
On Wed, 2026-01-07 at 13:47 +0100, Yoann Congal wrote:
>
> Le 07/01/2026 à 13:32, Paul Barker a écrit :
> > On Wed, 2026-01-07 at 12:19 +0000, Marko, Peter wrote:
> > >
> > > > -----Original Message-----
> > > > From: Paul Barker <paul@pbarker.dev<mailto:paul@pbarker.dev>>
> > > > Sent: Wednesday, January 7, 2026 12:49
> > > > To: yoann.congal@smile.fr<mailto:yoann.congal@smile.fr>; openembedded-core@lists.openembedded.org<mailto:openembedded-core@lists.openembedded.org>;
> > > > Marko, Peter (FT D EU SK BFS1) <Peter.Marko@siemens.com<mailto:Peter.Marko@siemens.com>>
> > > > Subject: Re: [OE-core][whinlatter 04/11] python3-urllib3: patch
> > > >
> > > > On Wed, 2026-01-07 at 09:08 +0100, Yoann Congal via
> > > > lists.openembedded.org<http://lists.openembedded.org> wrote:
> > > > > From: Peter Marko <peter.marko@siemens.com<mailto:peter.marko@siemens.com>>
> > > > >
> > > > > Pick patch per [1].
> > > > >
> > > > > [1] https://nvd.nist.gov/vuln/detail/CVE-2025-66471
> > > > >
> > > > > Signed-off-by: Peter Marko <peter.marko@siemens.com<mailto:peter.marko@siemens.com>>
> > > > > ---
> > > > >  .../python3-urllib3/CVE-2025-66471.patch      | 930 ++++++++++++++++++
> > > > >  .../python/python3-urllib3_2.5.0.bb<http://python3-urllib3_2.5.0.bb>           |   1 +
> > > > >  2 files changed, 931 insertions(+)
> > > > >  create mode 100644 meta/recipes-devtools/python/python3-urllib3/CVE-2025-
> > > > 66471.patch
> > > >
> > > > This seems like a very large patch for a CVE issue. The changelog entry
> > > > in the patch also says that the API of urllib3.response.ContentDecoder
> > > > is changed.
> > > >
> > > > We should look for a narrower fix, and only take this if there is no
> > > > other option.
> > >
> > > I originally didn't want to patch this CVE due to this reason (and didn't patch it in kirkstone).
> > > But since this has landed in scarthgap, I decided for the same in whinlatter for consistency.
> > > Should we revert it from scartghap?
> >
> > I don't think we need to rush to a decision.
>
> On my side, I need to do the whinlatter 5.3.1 release build on Monday.
> I propose to set this patch aside to not block the release and the other
> patches.

Agreed.

> For scarthgap, we can revert the current fix and add the "proper" fix
> when we have it. I'd rather avoid a patched->applicable transition on a CVE.

We don't need to do this immediately, let's take a little time to think
and see if others have any thoughts.

Ubuntu seem to have applied the patch with post-fixes :
https://git.launchpad.net/ubuntu/+source/python-urllib3/tree/debian/patches?h=ubuntu%2Fnoble-security
CVE-2025-66471.patch # the upstream patch
CVE-2025-66471-post1.patch  # Remove brotli version warning
CVE-2025-66471-fix1.patch # Revert fix for zstd
CVE-2025-66471-fix2.patch # Fix zstandard using unknown attribute

but also, has deem the fix too intrusive for most maintained releases: https://ubuntu.com/security/CVE-2025-66471#status

Debian has not patched: https://security-tracker.debian.org/tracker/CVE-2025-66471
Intrusive to backport; requires update for src:brotli for effective fix
The fix requires an updated src:brotli >= 1.2.0 for the fix to be effective,
which adds the optional output_buffer_limit option to avoid these attacks.

--
Yoann Congal
Smile ECS

[-- Attachment #2: Type: text/html, Size: 10241 bytes --]

Re: [OE-core][whinlatter 04/11] python3-urllib3: patch

[Yoann Congal]

On Wed Mar 4, 2026 at 12:10 PM CET, Peter Marko wrote:
> Hello Yoann, Paul,
>
> What shall we do with this patch?
> Drop or take?
>
> I also think that it’s intrusive, however having this fixed on older Yocto release and not fixed in newer is weird.
> https://git.openembedded.org/openembedded-core/commit/?h=scarthgap&id=d9f52c5f86bcc4716e384fe5c01c03d386d60446

Hello,

For context, here an update on status in other distros:
Debian did not fix it: 
https://security-tracker.debian.org/tracker/CVE-2025-66471

Ubuntu has not fixed for most releases:
https://ubuntu.com/security/CVE-2025-66471

Redhat did take the patch:
https://access.redhat.com/errata/RHSA-2026:1254

So the situation in other distros has not changed much.

I looked closer at the patch:
* There is indeed an API change:
    ContentDecoder.decompress(..., max_length: int = -1)
    BaseHTTPResponse._decode(..., max_length: int | None = None)
  But this has a default value so existing code will use that and
  preserve current behavior (uncompress without limit).
  That could be a problem for users that subclassed those but, a
  decompress() without max_length would have the CVE so better fix it
  and _decode() is not intended to be subclassed (as private?)
* The upgraded dependency to brotli >= 1.2.0:
  * is optional
  * existing brotli 1.1.0 (in meta-openembedded/scarthgap) will still
    work but generate a valid warning (the 1.1.0 version of brotli can't
    support fixes for this CVE)
* For what it's worth (not much), this patch was in released scarthgap
  5.0.15 for 1.5 months and yet we had no user reports.

I don't see how you could fix this CVE without changing the API you have
to limit the size of the decompressed data, but you also have to pass
the maximum size to the underlying decompressor somehow...

Interestingly, urllib3 has paid support available:
https://urllib3.readthedocs.io/en/latest/index.html#for-enterprise
Maybe an interested party can ask through that for a smaller fix?

In conclusion, I'm leaning toward taking the patch : while it is
definitely intrusive, some care was taken in it to ensure
compatibility and the breakages are inherent to the CVE.

Paul, would you agree?

Regards,

> Peter
>
>
> From: Yoann Congal <yoann.congal@smile.fr>
> Sent: Friday, January 30, 2026 11:34
> To: Paul Barker <paul@pbarker.dev>
> Cc: Marko, Peter (FT D EU SK BFS1) <Peter.Marko@siemens.com>; openembedded-core@lists.openembedded.org; Jiaying Song <jiaying.song.cn@windriver.com>
> Subject: Re: [OE-core][whinlatter 04/11] python3-urllib3: patch
>
>
>
> Le mer. 7 janv. 2026 à 15:05, Paul Barker <paul@pbarker.dev<mailto:paul@pbarker.dev>> a écrit :
> On Wed, 2026-01-07 at 13:47 +0100, Yoann Congal wrote:
>>
>> Le 07/01/2026 à 13:32, Paul Barker a écrit :
>> > On Wed, 2026-01-07 at 12:19 +0000, Marko, Peter wrote:
>> > >
>> > > > -----Original Message-----
>> > > > From: Paul Barker <paul@pbarker.dev<mailto:paul@pbarker.dev>>
>> > > > Sent: Wednesday, January 7, 2026 12:49
>> > > > To: yoann.congal@smile.fr<mailto:yoann.congal@smile.fr>; openembedded-core@lists.openembedded.org<mailto:openembedded-core@lists.openembedded.org>;
>> > > > Marko, Peter (FT D EU SK BFS1) <Peter.Marko@siemens.com<mailto:Peter.Marko@siemens.com>>
>> > > > Subject: Re: [OE-core][whinlatter 04/11] python3-urllib3: patch
>> > > >
>> > > > On Wed, 2026-01-07 at 09:08 +0100, Yoann Congal via
>> > > > lists.openembedded.org<http://lists.openembedded.org> wrote:
>> > > > > From: Peter Marko <peter.marko@siemens.com<mailto:peter.marko@siemens.com>>
>> > > > >
>> > > > > Pick patch per [1].
>> > > > >
>> > > > > [1] https://nvd.nist.gov/vuln/detail/CVE-2025-66471
>> > > > >
>> > > > > Signed-off-by: Peter Marko <peter.marko@siemens.com<mailto:peter.marko@siemens.com>>
>> > > > > ---
>> > > > >  .../python3-urllib3/CVE-2025-66471.patch      | 930 ++++++++++++++++++
>> > > > >  .../python/python3-urllib3_2.5.0.bb<http://python3-urllib3_2.5.0.bb>           |   1 +
>> > > > >  2 files changed, 931 insertions(+)
>> > > > >  create mode 100644 meta/recipes-devtools/python/python3-urllib3/CVE-2025-
>> > > > 66471.patch
>> > > >
>> > > > This seems like a very large patch for a CVE issue. The changelog entry
>> > > > in the patch also says that the API of urllib3.response.ContentDecoder
>> > > > is changed.
>> > > >
>> > > > We should look for a narrower fix, and only take this if there is no
>> > > > other option.
>> > >
>> > > I originally didn't want to patch this CVE due to this reason (and didn't patch it in kirkstone).
>> > > But since this has landed in scarthgap, I decided for the same in whinlatter for consistency.
>> > > Should we revert it from scartghap?
>> >
>> > I don't think we need to rush to a decision.
>>
>> On my side, I need to do the whinlatter 5.3.1 release build on Monday.
>> I propose to set this patch aside to not block the release and the other
>> patches.
>
> Agreed.
>
>> For scarthgap, we can revert the current fix and add the "proper" fix
>> when we have it. I'd rather avoid a patched->applicable transition on a CVE.
>
> We don't need to do this immediately, let's take a little time to think
> and see if others have any thoughts.
>
> Ubuntu seem to have applied the patch with post-fixes :
> https://git.launchpad.net/ubuntu/+source/python-urllib3/tree/debian/patches?h=ubuntu%2Fnoble-security
> CVE-2025-66471.patch # the upstream patch
> CVE-2025-66471-post1.patch  # Remove brotli version warning
> CVE-2025-66471-fix1.patch # Revert fix for zstd
> CVE-2025-66471-fix2.patch # Fix zstandard using unknown attribute
>
> but also, has deem the fix too intrusive for most maintained releases: https://ubuntu.com/security/CVE-2025-66471#status
>
> Debian has not patched: https://security-tracker.debian.org/tracker/CVE-2025-66471
> Intrusive to backport; requires update for src:brotli for effective fix
> The fix requires an updated src:brotli >= 1.2.0 for the fix to be effective,
> which adds the optional output_buffer_limit option to avoid these attacks.
>
> --
> Yoann Congal
> Smile ECS


-- 
Yoann Congal
Smile ECS

Re: [OE-core][whinlatter 04/11] python3-urllib3: patch

[Paul Barker]

[-- Attachment #1: Type: text/plain, Size: 2742 bytes --]

On Wed, 2026-03-04 at 16:15 +0100, Yoann Congal via
lists.openembedded.org wrote:
> On Wed Mar 4, 2026 at 12:10 PM CET, Peter Marko wrote:
> > Hello Yoann, Paul,
> > 
> > What shall we do with this patch?
> > Drop or take?
> > 
> > I also think that it’s intrusive, however having this fixed on older Yocto release and not fixed in newer is weird.
> > https://git.openembedded.org/openembedded-core/commit/?h=scarthgap&id=d9f52c5f86bcc4716e384fe5c01c03d386d60446
> 
> Hello,
> 
> For context, here an update on status in other distros:
> Debian did not fix it: 
> https://security-tracker.debian.org/tracker/CVE-2025-66471
> 
> Ubuntu has not fixed for most releases:
> https://ubuntu.com/security/CVE-2025-66471
> 
> Redhat did take the patch:
> https://access.redhat.com/errata/RHSA-2026:1254
> 
> So the situation in other distros has not changed much.
> 
> I looked closer at the patch:
> * There is indeed an API change:
>     ContentDecoder.decompress(..., max_length: int = -1)
>     BaseHTTPResponse._decode(..., max_length: int | None = None)
>   But this has a default value so existing code will use that and
>   preserve current behavior (uncompress without limit).
>   That could be a problem for users that subclassed those but, a
>   decompress() without max_length would have the CVE so better fix it
>   and _decode() is not intended to be subclassed (as private?)
> * The upgraded dependency to brotli >= 1.2.0:
>   * is optional
>   * existing brotli 1.1.0 (in meta-openembedded/scarthgap) will still
>     work but generate a valid warning (the 1.1.0 version of brotli can't
>     support fixes for this CVE)
> * For what it's worth (not much), this patch was in released scarthgap
>   5.0.15 for 1.5 months and yet we had no user reports.
> 
> I don't see how you could fix this CVE without changing the API you have
> to limit the size of the decompressed data, but you also have to pass
> the maximum size to the underlying decompressor somehow...
> 
> Interestingly, urllib3 has paid support available:
> https://urllib3.readthedocs.io/en/latest/index.html#for-enterprise
> Maybe an interested party can ask through that for a smaller fix?
> 
> In conclusion, I'm leaning toward taking the patch : while it is
> definitely intrusive, some care was taken in it to ensure
> compatibility and the breakages are inherent to the CVE.
> 
> Paul, would you agree?

Agreed - this has stewed for a while in our scarthgap branch and in
RHEL. I don't see any urgent follow up fixes from RHEL (see [1]). So, I
think it's ok to take.

[1]: https://gitlab.com/redhat/centos-stream/rpms/python-urllib3/-/commits/c8s?ref_type=heads

Best regards,

-- 
Paul Barker


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [OE-core][whinlatter 04/11] python3-urllib3: patch

[Yoann Congal]

On Thu Mar 5, 2026 at 10:39 AM CET, Paul Barker wrote:
> On Wed, 2026-03-04 at 16:15 +0100, Yoann Congal via
> lists.openembedded.org wrote:
>> On Wed Mar 4, 2026 at 12:10 PM CET, Peter Marko wrote:
>> > Hello Yoann, Paul,
>> > 
>> > What shall we do with this patch?
>> > Drop or take?
>> > 
>> > I also think that it’s intrusive, however having this fixed on older Yocto release and not fixed in newer is weird.
>> > https://git.openembedded.org/openembedded-core/commit/?h=scarthgap&id=d9f52c5f86bcc4716e384fe5c01c03d386d60446
>> 
>> Hello,
>> 
>> For context, here an update on status in other distros:
>> Debian did not fix it: 
>> https://security-tracker.debian.org/tracker/CVE-2025-66471
>> 
>> Ubuntu has not fixed for most releases:
>> https://ubuntu.com/security/CVE-2025-66471
>> 
>> Redhat did take the patch:
>> https://access.redhat.com/errata/RHSA-2026:1254
>> 
>> So the situation in other distros has not changed much.
>> 
>> I looked closer at the patch:
>> * There is indeed an API change:
>>     ContentDecoder.decompress(..., max_length: int = -1)
>>     BaseHTTPResponse._decode(..., max_length: int | None = None)
>>   But this has a default value so existing code will use that and
>>   preserve current behavior (uncompress without limit).
>>   That could be a problem for users that subclassed those but, a
>>   decompress() without max_length would have the CVE so better fix it
>>   and _decode() is not intended to be subclassed (as private?)
>> * The upgraded dependency to brotli >= 1.2.0:
>>   * is optional
>>   * existing brotli 1.1.0 (in meta-openembedded/scarthgap) will still
>>     work but generate a valid warning (the 1.1.0 version of brotli can't
>>     support fixes for this CVE)
>> * For what it's worth (not much), this patch was in released scarthgap
>>   5.0.15 for 1.5 months and yet we had no user reports.
>> 
>> I don't see how you could fix this CVE without changing the API you have
>> to limit the size of the decompressed data, but you also have to pass
>> the maximum size to the underlying decompressor somehow...
>> 
>> Interestingly, urllib3 has paid support available:
>> https://urllib3.readthedocs.io/en/latest/index.html#for-enterprise
>> Maybe an interested party can ask through that for a smaller fix?
>> 
>> In conclusion, I'm leaning toward taking the patch : while it is
>> definitely intrusive, some care was taken in it to ensure
>> compatibility and the breakages are inherent to the CVE.
>> 
>> Paul, would you agree?
>
> Agreed - this has stewed for a while in our scarthgap branch and in
> RHEL. I don't see any urgent follow up fixes from RHEL (see [1]). So, I
> think it's ok to take.
>
> [1]: https://gitlab.com/redhat/centos-stream/rpms/python-urllib3/-/commits/c8s?ref_type=heads
>
> Best regards,

Peter, can you send a updated version of the patch for the latest
whinlatter? (my trivial merge resulted in an unapplicable patch)

Thanks!
-- 
Yoann Congal
Smile ECS