Proposed incompatible security update for llhttp in EPEL9

[Ben Beasley]

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-upgrad...

[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

[Troy Dawson]

On Tue, Aug 8, 2023 at 4:11 PM Ben Beasley <code(a)musicinmybrain.net&gt; 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-upgrad...
>
>  [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

[Carl George]

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(a)redhat.com&gt; wrote:
>  On Tue, Aug 8, 2023 at 4:11 PM Ben Beasley <code(a)musicinmybrain.net&gt; 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-upgrad...
> >
> > [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(a)lists.fedoraproject.org
>  To unsubscribe send an email to epel-devel-leave(a)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/[e-mail]...
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue


-- 
Carl George

[Troy Dawson]

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(a)redhat.com&gt; 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(a)redhat.com&gt; wrote:
>  >
>  > On Tue, Aug 8, 2023 at 4:11 PM Ben Beasley <code(a)musicinmybrain.net&gt;
>  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-upgrad...
>  >>
>  >> [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(a)lists.fedoraproject.org
>  > To unsubscribe send an email to epel-devel-leave(a)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/[e-mail]...
>  > Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue
>
>
>
>  --
>  Carl George
>  _______________________________________________
>  epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to epel-devel-leave(a)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/[e-mail]...
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue
>

Proposed incompatible security update (again) for llhttp in EPEL9

[Ben Beasley]

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-upgrad...

[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

Proposed incompatible security update (again) for llhttp in EPEL9

[Ben Beasley]

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-upgrad...
>
> [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
>

Proposed incompatible security update (again) for llhttp in EPEL9

[Troy Dawson]

On Tue, Nov 28, 2023 at 8:37 AM Ben Beasley <code(a)musicinmybrain.net&gt; 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-upgrad...
>
>  [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
>
>  
This exception, as well as a permanent exception, was approved this week in
the EPEL Steering Committee meeting.

Troy