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 <[email protected]> > Sent: Friday, January 30, 2026 11:34 > To: Paul Barker <[email protected]> > Cc: Marko, Peter (FT D EU SK BFS1) <[email protected]>; > [email protected]; Jiaying Song > <[email protected]> > Subject: Re: [OE-core][whinlatter 04/11] python3-urllib3: patch > > > > Le mer. 7 janv. 2026 à 15:05, Paul Barker > <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> >> > > > Sent: Wednesday, January 7, 2026 12:49 >> > > > To: [email protected]<mailto:[email protected]>; >> > > > [email protected]<mailto:[email protected]>; >> > > > Marko, Peter (FT D EU SK BFS1) >> > > > <[email protected]<mailto:[email protected]>> >> > > > 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 >> > > > > <[email protected]<mailto:[email protected]>> >> > > > > >> > > > > Pick patch per [1]. >> > > > > >> > > > > [1] https://nvd.nist.gov/vuln/detail/CVE-2025-66471 >> > > > > >> > > > > Signed-off-by: Peter Marko >> > > > > <[email protected]<mailto:[email protected]>> >> > > > > --- >> > > > > .../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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#232382): https://lists.openembedded.org/g/openembedded-core/message/232382 Mute This Topic: https://lists.openembedded.org/mt/117132726/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
