[EPEL-devel] Re: Proposed incompatible security update for llhttp in EPEL9
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 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 wrote: > > > > On Tue, Aug 8, 2023 at 4:11 PM Ben Beasley > 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/#process_for_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/ > >> > >> [8] https://pagure.io/fesco/issue/3049 > > > > > > 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-le...@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.org > > 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-le...@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.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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:
[EPEL-devel] Re: Proposed incompatible security update for llhttp in EPEL9
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 wrote: > > On Tue, Aug 8, 2023 at 4:11 PM Ben Beasley 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/#process_for_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/ >> >> [8] https://pagure.io/fesco/issue/3049 > > > 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-le...@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.org > 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-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Re: Proposed incompatible security update for llhttp in EPEL9
On Tue, Aug 8, 2023 at 4:11 PM Ben Beasley 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/#process_for_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/ > > [8] https://pagure.io/fesco/issue/3049 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-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
