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
signature.asc
Description: This is a digitally signed message part
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#232475): https://lists.openembedded.org/g/openembedded-core/message/232475 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]] -=-=-=-=-=-=-=-=-=-=-=-
