This email proposes upgrading the llhttp package in EPEL9 from 6.0.10 to 8.1.1, 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 llhttp prior to 8.1.1 are affected by CVE-2023-30589[2], an HTTP request smuggling vulnerability rated 7.7 HIGH in CVSS v3 and rated Moderate by Red Hat. The GitHub advisory for llhttp is GHSA-cggh-pq45-6h9x[3]; the advisory for python-aiohttp is GHSA-45c4-8wx5-qw6w[4]. Upstream for python-aiohttp fixed this by updating llhttp (which they bundle, but we unbundle) in release 3.8.5.
I am not comfortable attempting to backport the fix to an older release of llhttp. My preferred solution would be to update llhttp to 8.1.1[5] and (in the same side tag) update python-aiohttp to 3.8.5[6]. The ABI break in llhttp would only affect python-aiohttp; the python-aiohttp update itself is compatible (by upstream intent, and verified in COPR[7]); and a number of packages that depend on python-aiohttp would benefit from the fix.
If this exception request is not approved, my fallback plan is to propose rebuilding python-aiohttp in EPEL9 with AIOHTTP_NO_EXTENSIONS=1, which would convert it to a pure-Python package. This is a documented mitigation, but comes with potentially serious performance regressions, again affecting a number of dependent packages. The llhttp package would become a leaf package and would remain unpatched.
The same incompatible update was approved by FESCo for Fedora 37[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/...
[2] https://access.redhat.com/security/cve/CVE-2023-30589
[3] https://github.com/advisories/GHSA-cggh-pq45-6h9x
[4] https://github.com/aio-libs/aiohttp/security/advisories/GHSA-45c4-8wx5-qw6w
[5] https://src.fedoraproject.org/rpms/llhttp/pull-request/14
[6] https://src.fedoraproject.org/rpms/python-aiohttp/pull-request/26
[7] https://copr.fedorainfracloud.org/coprs/music/aiohttp-epel9/packages/
On Tue, Aug 8, 2023 at 4:11 PM Ben Beasley code@musicinmybrain.net wrote:
This email proposes upgrading the llhttp package in EPEL9 from 6.0.10 to 8.1.1, 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 llhttp prior to 8.1.1 are affected by CVE-2023-30589[2], an HTTP request smuggling vulnerability rated 7.7 HIGH in CVSS v3 and rated Moderate by Red Hat. The GitHub advisory for llhttp is GHSA-cggh-pq45-6h9x[3]; the advisory for python-aiohttp is GHSA-45c4-8wx5-qw6w[4]. Upstream for python-aiohttp fixed this by updating llhttp (which they bundle, but we unbundle) in release 3.8.5.
I am not comfortable attempting to backport the fix to an older release of llhttp. My preferred solution would be to update llhttp to 8.1.1[5] and (in the same side tag) update python-aiohttp to 3.8.5[6]. The ABI break in llhttp would only affect python-aiohttp; the python-aiohttp update itself is compatible (by upstream intent, and verified in COPR[7]); and a number of packages that depend on python-aiohttp would benefit from the fix.
If this exception request is not approved, my fallback plan is to propose rebuilding python-aiohttp in EPEL9 with AIOHTTP_NO_EXTENSIONS=1, which would convert it to a pure-Python package. This is a documented mitigation, but comes with potentially serious performance regressions, again affecting a number of dependent packages. The llhttp package would become a leaf package and would remain unpatched.
The same incompatible update was approved by FESCo for Fedora 37[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/...
[2] https://access.redhat.com/security/cve/CVE-2023-30589
[3] https://github.com/advisories/GHSA-cggh-pq45-6h9x
[4] https://github.com/aio-libs/aiohttp/security/advisories/GHSA-45c4-8wx5-qw6w
[5] https://src.fedoraproject.org/rpms/llhttp/pull-request/14
[6] https://src.fedoraproject.org/rpms/python-aiohttp/pull-request/26
[7] https://copr.fedorainfracloud.org/coprs/music/aiohttp-epel9/packages/
Thank you for the nice write-up.
I have created an EPEL issue. Not really for discussion but more for voting and make sure this is on the meeting agendas. https://pagure.io/epel/issue/241
Troy
Thanks Ben for following the incompat process and for the detailed email. It makes sense to me, the plan is sound, and I plan to vote yes when we hold the official vote in next week's steering committee meeting.
On Wed, Aug 9, 2023 at 1:35 PM Troy Dawson tdawson@redhat.com wrote:
On Tue, Aug 8, 2023 at 4:11 PM Ben Beasley code@musicinmybrain.net wrote:
This email proposes upgrading the llhttp package in EPEL9 from 6.0.10 to 8.1.1, 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 llhttp prior to 8.1.1 are affected by CVE-2023-30589[2], an HTTP request smuggling vulnerability rated 7.7 HIGH in CVSS v3 and rated Moderate by Red Hat. The GitHub advisory for llhttp is GHSA-cggh-pq45-6h9x[3]; the advisory for python-aiohttp is GHSA-45c4-8wx5-qw6w[4]. Upstream for python-aiohttp fixed this by updating llhttp (which they bundle, but we unbundle) in release 3.8.5.
I am not comfortable attempting to backport the fix to an older release of llhttp. My preferred solution would be to update llhttp to 8.1.1[5] and (in the same side tag) update python-aiohttp to 3.8.5[6]. The ABI break in llhttp would only affect python-aiohttp; the python-aiohttp update itself is compatible (by upstream intent, and verified in COPR[7]); and a number of packages that depend on python-aiohttp would benefit from the fix.
If this exception request is not approved, my fallback plan is to propose rebuilding python-aiohttp in EPEL9 with AIOHTTP_NO_EXTENSIONS=1, which would convert it to a pure-Python package. This is a documented mitigation, but comes with potentially serious performance regressions, again affecting a number of dependent packages. The llhttp package would become a leaf package and would remain unpatched.
The same incompatible update was approved by FESCo for Fedora 37[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/...
[2] https://access.redhat.com/security/cve/CVE-2023-30589
[3] https://github.com/advisories/GHSA-cggh-pq45-6h9x
[4] https://github.com/aio-libs/aiohttp/security/advisories/GHSA-45c4-8wx5-qw6w
[5] https://src.fedoraproject.org/rpms/llhttp/pull-request/14
[6] https://src.fedoraproject.org/rpms/python-aiohttp/pull-request/26
[7] https://copr.fedorainfracloud.org/coprs/music/aiohttp-epel9/packages/
Thank you for the nice write-up.
I have created an EPEL issue. Not really for discussion but more for voting and make sure this is on the meeting agendas. https://pagure.io/epel/issue/241
Troy
epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org 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@lists.fedoraproject... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
The voting at the EPEL Steering Committee meeting was unanimous, with no negative votes. Please proceed.
On Wed, Aug 9, 2023 at 1:20 PM Carl George carl@redhat.com wrote:
Thanks Ben for following the incompat process and for the detailed email. It makes sense to me, the plan is sound, and I plan to vote yes when we hold the official vote in next week's steering committee meeting.
On Wed, Aug 9, 2023 at 1:35 PM Troy Dawson tdawson@redhat.com wrote:
On Tue, Aug 8, 2023 at 4:11 PM Ben Beasley code@musicinmybrain.net
wrote:
This email proposes upgrading the llhttp package in EPEL9 from 6.0.10 to 8.1.1, 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 llhttp prior to 8.1.1 are affected by CVE-2023-30589[2], an HTTP request smuggling vulnerability rated 7.7 HIGH in CVSS v3 and rated Moderate by Red Hat. The GitHub advisory for llhttp is GHSA-cggh-pq45-6h9x[3]; the advisory for python-aiohttp is GHSA-45c4-8wx5-qw6w[4]. Upstream for python-aiohttp fixed this by updating llhttp (which they bundle, but we unbundle) in release 3.8.5.
I am not comfortable attempting to backport the fix to an older release of llhttp. My preferred solution would be to update llhttp to 8.1.1[5] and (in the same side tag) update python-aiohttp to 3.8.5[6]. The ABI break in llhttp would only affect python-aiohttp; the python-aiohttp update itself is compatible (by upstream intent, and verified in COPR[7]); and a number of packages that depend on python-aiohttp would benefit from the fix.
If this exception request is not approved, my fallback plan is to propose rebuilding python-aiohttp in EPEL9 with AIOHTTP_NO_EXTENSIONS=1, which would convert it to a pure-Python package. This is a documented mitigation, but comes with potentially serious performance regressions, again affecting a number of dependent packages. The llhttp package would become a leaf package and would remain unpatched.
The same incompatible update was approved by FESCo for Fedora 37[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/...
[2] https://access.redhat.com/security/cve/CVE-2023-30589
[3] https://github.com/advisories/GHSA-cggh-pq45-6h9x
[4]
https://github.com/aio-libs/aiohttp/security/advisories/GHSA-45c4-8wx5-qw6w
[5] https://src.fedoraproject.org/rpms/llhttp/pull-request/14
[6] https://src.fedoraproject.org/rpms/python-aiohttp/pull-request/26
[7]
https://copr.fedorainfracloud.org/coprs/music/aiohttp-epel9/packages/
Thank you for the nice write-up.
I have created an EPEL issue. Not really for discussion but more for
voting and make sure this is on the meeting agendas.
https://pagure.io/epel/issue/241
Troy
epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org 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@lists.fedoraproject...
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
-- Carl George _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org 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@lists.fedoraproject... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
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/...
[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
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/...
[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
On Tue, Nov 28, 2023 at 8:37 AM Ben Beasley code@musicinmybrain.net 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/...
[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
This exception, as well as a permanent exception, was approved this week in the EPEL Steering Committee meeting.
Troy
epel-devel@lists.fedoraproject.org
-
Ben Beasley -
Carl George -
Troy Dawson