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

[Paul Barker <paul@pbarker.dev>]

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