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

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

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