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

["Yoann Congal" <yoann.congal@smile.fr>]

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