Since I sent the original email, I learned that aiohttp 3.9.0, a
compatible feature release, also fixes two additional CVE’s,
CVE-2023-49081[1] and CVE-2023-49082[2]. A COPR impact check[3] shows
that the proposed llhttp update will allow python-aiohttp to be safely
updated all the way from 3.8.5 to 3.9.1 in EPEL9, fixing these CVE’s as
well. (As explained in the Bugzilla issues, I don’t have any plans to
work on the EPEL8 branch.)
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2252239
[2] https://bugzilla.redhat.com/show_bug.cgi?id=2252250
[3] https://copr.fedorainfracloud.org/coprs/music/aiohttp-el9/packages/
On 11/28/23 11:36, Ben Beasley wrote:
This email proposes upgrading the llhttp package in EPEL9 from 8.1.1
to 9.1.3, which would break the ABI and bump the SONAME version, under
the EPEL Incompatible Upgrades Policy[1].
The llhttp package is a C library (transpiled from TypeScript) that
provides the low-level HTTP support for NodeJS and for python-aiohttp.
Currently, only python-aiohttp depends on the llhttp package in EPEL9.
Versions of python-aiohttp prior to 3.8.6[2] are affected by
CVE-2023-47627[3][4], an HTTP request/response smuggling vulnerability
rated 5.3 in CVSS v3 and rated Moderate by Red Hat. This was reported
as RHBZ#2249825[5]. Since the flaw is only in the pure-Python parser,
and we compile the llhttp-based parser, this affects only code using
the AIOHTTP_NO_EXTENSIONS environment variable. Updating aiohttp from
3.8.5 to 3.8.6 to fix that still requires updating llhttp from 8.x to
9.x. Additionally, according to the release notes this includes an
llhttp-related security fix[6] with no assigned CVE, which provides
added motivation to update.
The ABI break in llhttp would only affect python-aiohttp. The
python-aiohttp update itself is compatible (by upstream intent, and as
already demonstrated in Rawhide and F39/F38); and a large list of
packages that depend on python-aiohttp would benefit from the fix. The
necessary rebuild would be conducted in a side tag.
The same incompatible update was approved by FESCo for Fedora 38 and
39[7]. Furthermore, it appears that FESCo will approve a permanent
exception for llhttp[8].
The purpose of this email is to document and explain the proposed
update, to begin the minimum one-week discussion period mandated by
the EPEL Incompatible Upgrades Policy, and to request that the update
be added to the agenda for an upcoming EPEL meeting.
[1]
https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/#process_for_incompatible_upgrades
[2] https://github.com/aio-libs/aiohttp/releases/tag/v3.8.6
[3] https://access.redhat.com/security/cve/CVE-2023-47627
[4]
https://github.com/aio-libs/aiohttp/security/advisories/GHSA-gfw2-4jvh-wgfg
[5] https://bugzilla.redhat.com/show_bug.cgi?id=2249825
[6] https://github.com/aio-libs/aiohttp/releases/tag/v3.8.6
[7] https://pagure.io/fesco/issue/3106
[8] https://pagure.io/fesco/issue/3115
--
_______________________________________________
epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
