[EPEL-devel] Proposed incompatible upgrade for re2 in EPEL10
This email is the first step in a proposed update of the re2 package from version 20220601 to 20240702 in EPEL10[1]. This would be an ABI-incompatible update[2] that would bump the SONAME version from 9 to 11. In addition to two years of assorted bugfixes, which are mostly only documented in the commit messages[3], this update would allow us to ship the maintained, official Python bindings[4] as a python3-google-re2 subpackage. While there are a quite a few packages that depend on re2 in Fedora, it’s still a leaf package in EPEL10. I’m hoping that this fact, along with the benefits of shipping a current version with Python bindings and the fact that EPEL10 has not yet been officially launched for end-users, will help make this an uncontroversial proposal. [1] https://src.fedoraproject.org/rpms/re2/pull-request/9 [2] https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/#process_for_incompatible_upgrades [3] https://github.com/google/re2/commits/2024-07-02 [4] https://pypi.org/project/google-re2/ -- ___ 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: Incompatible update of llhttp from 9.1.3 to 9.2.1 in EPEL9
I have pushed this update to stable. On 4/11/24 8:18 PM, Ben Beasley wrote: I have just submitted for testing https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-ce142428af, which updates llhttp in EPEL9 from 9.1.3 to 9.2.1 and fixes CVE-2024-27982[1], an HTTP request smuggling vulnerability. Version 9.2.0 also included a number of bug fixes[2]. This is an ABI-incompatible update, and the SONAME version changes. Because the EPEL Steering Committee has previously approved a permanent exception for incompatible upgrades of llhttp, I have bypassed the usual proposal and discussion of this update on the epel-devel mailing list. However, I am following the other parts of the incompatible updates process: this announcement, at least one week in testing with auto-push disabled, and a follow-up announcement on this list once I have pushed the update to stable. The only package in EPEL9 that uses llhttp is python-aiohttp; the update also backports support for llhttp 9.2.1 to the current aiohttp release, 3.9.3. I expect that the aiohttp project will soon release a compatible patch release 3.9.4 that directly supports llhttp 9.2.1. If you have software not packaged in EPEL9 that depends directly on llhttp, you will need to rebuild it due to the ABI changes. It is possible that source code changes may be required if (like python-aiohttp) you use almost the entire API of llhttp, or if you have very thorough tests that reveal small changes in llhttp’s behavior. Straightforward uses of llhttp are very likely to recompile without modification. I have no plans to attempt a build of llhttp or any update of python-aiohttp in EPEL8. [1] https://nodejs.org/en/blog/vulnerability/april-2024-security-releases/#http-request-smuggling-via-content-length-obfuscation---cve-2024-27982---medium [2] https://github.com/nodejs/llhttp/releases/tag/release%2Fv9.2.0 -- ___ 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] Incompatible update of llhttp from 9.1.3 to 9.2.1 in EPEL9
I have just submitted for testing https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-ce142428af, which updates llhttp in EPEL9 from 9.1.3 to 9.2.1 and fixes CVE-2024-27982[1], an HTTP request smuggling vulnerability. Version 9.2.0 also included a number of bug fixes[2]. This is an ABI-incompatible update, and the SONAME version changes. Because the EPEL Steering Committee has previously approved a permanent exception for incompatible upgrades of llhttp, I have bypassed the usual proposal and discussion of this update on the epel-devel mailing list. However, I am following the other parts of the incompatible updates process: this announcement, at least one week in testing with auto-push disabled, and a follow-up announcement on this list once I have pushed the update to stable. The only package in EPEL9 that uses llhttp is python-aiohttp; the update also backports support for llhttp 9.2.1 to the current aiohttp release, 3.9.3. I expect that the aiohttp project will soon release a compatible patch release 3.9.4 that directly supports llhttp 9.2.1. If you have software not packaged in EPEL9 that depends directly on llhttp, you will need to rebuild it due to the ABI changes. It is possible that source code changes may be required if (like python-aiohttp) you use almost the entire API of llhttp, or if you have very thorough tests that reveal small changes in llhttp’s behavior. Straightforward uses of llhttp are very likely to recompile without modification. I have no plans to attempt a build of llhttp or any update of python-aiohttp in EPEL8. [1] https://nodejs.org/en/blog/vulnerability/april-2024-security-releases/#http-request-smuggling-via-content-length-obfuscation---cve-2024-27982---medium [2] https://github.com/nodejs/llhttp/releases/tag/release%2Fv9.2.0 -- ___ 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: EPEL-ANNOUNCE Incompatible update of llhttp in EPEL9
I have pushed this update to stable. This is the final announcement prescribed by the EPEL Incompatible Upgrades Policy, https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/ On 12/13/23 08:43, Ben Beasley wrote: I have just submitted for testing https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-4b1b8b8b25, which updates llhttp from 8.1.1 to 9.1.3 in EPEL9. This is an ABI-incompatible update, and the SONAME version changes. There are also some minor API changes. The only package in EPEL9 that uses llhttp is python-aiohttp, and the update also compatibly updates it from 3.8.5 to its latest release, 3.9.1. Together, these updates fix a number of security issues, including CVE-2023-47627, CVE-2023-49081, and CVE-2023-49082. A COPR impact check in https://copr.fedorainfracloud.org/coprs/music/aiohttp-epel9/ indicates there should be no impact on any dependent packages in EPEL9. If you have software not packaged in EPEL9 that depends directly on llhttp, you will need to rebuild it due to the ABI changes. It is possible that source code changes may be required if (like python-aiohttp) you use almost the entire API of llhttp, or if you have very thorough tests that reveal small changes in llhttp’s behavior. Straightforward uses of llhttp are likely to recompile without modification. If you have software not packaged in EPEL9 that depends directly on python-aiohttp, you should not need to do anything, but you might choose to review the changelogs for releases 3.8.6, 3.9.0, and 3.9.1 here for full details on the changes included in this update: https://github.com/aio-libs/aiohttp/blob/v3.9.1/CHANGES.rst#391-2023-11-26 I have no plans to attempt a build of llhttp or any update of python-aiohttp in EPEL8. This is an incompatible update under the EPEL Incompatible Upgrades Policy, https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/. It was approved by the EPEL Steering Committee: https://pagure.io/epel/issue/262. -- ___ epel-announce mailing list -- epel-annou...@lists.fedoraproject.org To unsubscribe send an email to epel-announce-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-annou...@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: 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] Incompatible update of llhttp in EPEL9
I have just submitted for testing https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-4b1b8b8b25, which updates llhttp from 8.1.1 to 9.1.3 in EPEL9. This is an ABI-incompatible update, and the SONAME version changes. There are also some minor API changes. The only package in EPEL9 that uses llhttp is python-aiohttp, and the update also compatibly updates it from 3.8.5 to its latest release, 3.9.1. Together, these updates fix a number of security issues, including CVE-2023-47627, CVE-2023-49081, and CVE-2023-49082. A COPR impact check in https://copr.fedorainfracloud.org/coprs/music/aiohttp-epel9/ indicates there should be no impact on any dependent packages in EPEL9. If you have software not packaged in EPEL9 that depends directly on llhttp, you will need to rebuild it due to the ABI changes. It is possible that source code changes may be required if (like python-aiohttp) you use almost the entire API of llhttp, or if you have very thorough tests that reveal small changes in llhttp’s behavior. Straightforward uses of llhttp are likely to recompile without modification. If you have software not packaged in EPEL9 that depends directly on python-aiohttp, you should not need to do anything, but you might choose to review the changelogs for releases 3.8.6, 3.9.0, and 3.9.1 here for full details on the changes included in this update: https://github.com/aio-libs/aiohttp/blob/v3.9.1/CHANGES.rst#391-2023-11-26 I have no plans to attempt a build of llhttp or any update of python-aiohttp in EPEL8. This is an incompatible update under the EPEL Incompatible Upgrades Policy, https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/. It was approved by the EPEL Steering Committee: https://pagure.io/epel/issue/262. -- ___ 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 (again) for llhttp in EPEL9
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@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] Proposed incompatible security update (again) for llhttp in EPEL9
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@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: Incompatible security update for llhttp in EPEL9
I just pushed this update to stable. On 8/17/23 9:08 AM, Ben Beasley wrote: This email announces that the llhttp package in EPEL9 will be upgraded from 6.0.10 to 8.1.1[1], which breaks the ABI and bumps the SONAME version, as discussed[2] and approved[3] under the EPEL Incompatible Upgrades Policy[4]. At the same time, python-aiohttp will be upgraded from 3.8.4 to 3.8.5. Currently, only python-aiohttp depends on the llhttp package in EPEL9. This update fixes CVE-2023-30589[5]. Users of the python-aiohttp package, or of the various packages that depend on it, will benefit from this security fix but should not expect any incompatibilities or performance regressions. In the unlikely case that you are maintaining software that depends directly on the llhttp package, you will need to rebuild it due to the SONAME version bump. Breaking changes from 6.0.10 to 8.1.1 include a couple of HTTP parsing changes (“do not allow whitespaces after start line,” “require semicolon to start chunk parameters”) and one API change (“rename status code 509”). Most programs will not require source code changes. [1] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-e2fcc4af81 [2] https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/DLJ4ILU6QHXN2YYHTHNTAF2ED6YRP23H/ [3] https://pagure.io/epel/issue/241 [4] https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/#process_for_incompatible_upgrades [5] https://access.redhat.com/security/cve/CVE-2023-30589 [4] https://github.com/advisories/GHSA-cggh-pq45-6h9x [5] https://github.com/aio-libs/aiohttp/security/advisories/GHSA-45c4-8wx5-qw6w ___ 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] Incompatible security update for llhttp in EPEL9
This email announces that the llhttp package in EPEL9 will be upgraded from 6.0.10 to 8.1.1[1], which breaks the ABI and bumps the SONAME version, as discussed[2] and approved[3] under the EPEL Incompatible Upgrades Policy[4]. At the same time, python-aiohttp will be upgraded from 3.8.4 to 3.8.5. Currently, only python-aiohttp depends on the llhttp package in EPEL9. This update fixes CVE-2023-30589[5]. Users of the python-aiohttp package, or of the various packages that depend on it, will benefit from this security fix but should not expect any incompatibilities or performance regressions. In the unlikely case that you are maintaining software that depends directly on the llhttp package, you will need to rebuild it due to the SONAME version bump. Breaking changes from 6.0.10 to 8.1.1 include a couple of HTTP parsing changes (“do not allow whitespaces after start line,” “require semicolon to start chunk parameters”) and one API change (“rename status code 509”). Most programs will not require source code changes. [1] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-e2fcc4af81 [2] https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/thread/DLJ4ILU6QHXN2YYHTHNTAF2ED6YRP23H/ [3] https://pagure.io/epel/issue/241 [4] https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/#process_for_incompatible_upgrades [5] https://access.redhat.com/security/cve/CVE-2023-30589 [4] https://github.com/advisories/GHSA-cggh-pq45-6h9x [5] https://github.com/aio-libs/aiohttp/security/advisories/GHSA-45c4-8wx5-qw6w ___ 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] Proposed incompatible security update for llhttp in EPEL9
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 ___ 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] Retiring flintqs in EPEL7/8/9
As previously proposed on the epel-devel mailing list, and in accordance with the EPEL Retirement Policy: Process: Security Reasons[1], I will be retiring the flintqs package in EPEL7, EPEL8, and EPEL9 today. When I took over maintenance of the flintqs package[2]—which contains William Hart’s quadratic sieve implementation, as modified for sagemath—I built it for EPEL7, EPEL8, and EPEL9. My thoughts were, “Why not? Someone might find it useful.” It was recently pointed out[3][4] that the flintqs command-line tool uses temporary files in unsafe ways[5], which could potentially represent an exploitable security vulnerability; this has been assigned CVE-2023-29465[6]. There is no immediate patch available; while one could surely be constructed, the sagemath project plans to incorporate the factorization algorithm directly in sagemath and discontinue support of the vulnerable command-line tool rather than fixing it[7]. Since sagemath is not packaged in any of the EPEL releases, and flintqs is therefore a leaf package, I am handling this security report by retiring flintqs in all three EPELs. Anyone who does need FlintQS on EL will need to consider their security threat model, then build it from source—either by cloning the upstream GitHub repository, or, for the time being, by rebuilding the Fedora source RPM. Note, however, that the Fedora package will also be retired as soon as it is no longer needed by sagemath. [1] https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/#process_security_reasons [2] https://src.fedoraproject.org/rpms/flintqs [3] https://bugzilla.redhat.com/show_bug.cgi?id=2185301 [4] https://github.com/sagemath/FlintQS/issues/3 [5] https://owasp.org/www-community/vulnerabilities/Insecure_Temporary_File [6] https://nvd.nist.gov/vuln/detail/CVE-2023-29465 [7] https://github.com/sagemath/sage/pull/35419 ___ 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] Intent to retire flintqs in EPEL7, EPEL8, and EPEL9 for security reasons
When I took over maintenance of the flintqs package[1]—which contains William Hart’s quadratic sieve implementation, as modified for sagemath—I built it for EPEL7, EPEL8, and EPEL9. My thoughts were, “Why not? Someone might find it useful.” It was recently pointed out[2][3] that the flintqs command-line tool uses temporary files in unsafe ways[4], which could potentially represent an exploitable security vulnerability; this has been assigned CVE-2023-29465[5]. There is no immediate patch available; while one could surely be constructed, the sagemath project plans to incorporate the factorization algorithm directly in sagemath and discontinue support of the vulnerable command-line tool rather than fixing it[6]. Since sagemath is not packaged in any of the EPEL releases, and flintqs is therefore a leaf package, I plan to handle this security report by retiring flintqs in all three EPELs. This email is the beginning of that process as prescribed in the EPEL Retirement Policy: Process: Security Reasons[7]. I doubt there will be any objections, but the process requires a one-week discussion period, so I will follow up on the epel-announce list and do the retirements no earlier than 2023-03-17. [1] https://src.fedoraproject.org/rpms/flintqs [2] https://bugzilla.redhat.com/show_bug.cgi?id=2185301 [3] https://github.com/sagemath/FlintQS/issues/3 [4] https://owasp.org/www-community/vulnerabilities/Insecure_Temporary_File [5] https://nvd.nist.gov/vuln/detail/CVE-2023-29465 [6] https://github.com/sagemath/sage/pull/35419 [7] https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/#process_security_reasons ___ 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: How to remove builds from EPEL 9 Next?
Thanks for asking this question (and for the heads-up that the problem is fixed). I’ll do as Neal suggested for python-Rtree, as well as a couple of other packages (python-mapbox-earcut, iml) that were in a similar situtation. – Ben On 5/27/22 08:37, Neal Gompa wrote: On Fri, May 27, 2022 at 8:00 AM Miro Hrončok wrote: Hey EPEL folks, The python-Rtree package was unable to build in EPEL 9 before RHEL 9.0 GA, as the frozen set of packages from CentOS Stream made it segfault during build. So it was build in EPEL 9 Next instead, as python-Rtree-1.0.0-2.el9.next. Now, it builds in regular EPEL 9 successfully (as the segfault was fixed in the meantime). So, we should probbaly build and ship the package in EPEL 9. But we should also remove/obsolete/replace the EPEL 9 build somehow. I suppose there are multiple options here: 1. bump and build in epel9, so the EVR is higher, do nothing with epel9-next 2. build in epel9, untag the old epel9-next build Generally, you bump to raise the EVR and then the automation Troy has can untag everything in EPEL next that's lower than what's in EPEL. What is the general guideline in this situation? Related, but not necessarily blocking question: Should EPEL 9 Next be purged after each RHEL 9.Y release and all the purged builds built in regular EPEL 9 instead? Yes, please, for the sake of my mirror hosting space... ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
