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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#232476): https://lists.openembedded.org/g/openembedded-core/message/232476 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]] -=-=-=-=-=-=-=-=-=-=-=-
