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

Paul Barker
2026-03-05T09:39:52Z

[-- 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 --]