epel-announce April 2023

epel-announce@lists.fedoraproject.org

2 participants
3 discussions

Upcoming removal of rust2rpm + major Rust packaging toolchain update for EPEL 9
by Fabio Valentini 12 May '23

12 May '23

Hello EPEL packagers, The latest version of the Rust packaging toolchain will soon be available for EPEL 9 (i.e. rust2rpm v24, rust-packaging v24, and cargo2rpm v0.1). This is a major upgrade from rust2rpm v21 which is currently in EPEL 9, but also comes with the drawback that it now requires Python >= 3.10. However, I have split the Rust packaging tools into three separate projects (previously everything was in a monorepo) to make packaging them easier: The two components which are needed at build-time (RPM macros + the cargo2rpm Python module that powers them) can still be built for EPEL 9, as cargo2rpm has no third-party dependencies and only needs Python >= 3.10, and will hence be built with python3.11 on EPEL 9 as soon as that is available. The spec generator (rust2rpm) has also been split off from rust-packaging into a separate package, which will *not* be available on EPEL 9. rust2rpm requires Python >= 3.10, but it also has a few non-trivial third-party dependencies (most notably, jinja2). Since most Rust packagers primarily work on Fedora, I don't think the effort of packaging all missing dependencies for Python 3.11 just to make /usr/bin/rust2rpm available for EPEL 9 would be worth it. There are three Pull Requests which will implement this update: https://src.fedoraproject.org/rpms/cargo2rpm/pull-request/1 https://src.fedoraproject.org/rpms/rust-packaging/pull-request/6 https://src.fedoraproject.org/rpms/epel-rpm-macros/pull-request/65 (kudos to @gotmax23!) These changes (i.e. rust-packaging v24 + cargo2rpm) have now been live in "production" in Fedora for over a week, and based on user and CI feedback, I expect these updates to cause no regressions on EPEL 9. Fabio

2 1

Incompatible change in apptainer-suid-1.1.8 now in epel-testing
by Dave Dykstra 11 May '23

11 May '23

The apptainer-suid package version 1.1.8 now in epel-testing has an incompatible change because of a security vulnerability. The change is that a new option "allow setuid-mount extfs" was added which defaults to no, preventing ordinary users from mounting ext3 filesystems in setuid-root mode. Those filesystems are used by a subset of users primarily for the overlay feature which adds changes on top of a base container image. If unprivileged user namespaces are enabled, users will be able to still mount ext3 filesystems by using the "-u/--userns" option or if the apptainer-suid package is removed. If system administrators review the vulnerability description at https://github.com/apptainer/apptainer/security/advisories/GHSA-j4rf-7357-f… and decide they still want to allow setuid-root access to this feature, they can enable it by setting "allow setuid-mount extfs = yes" in /etc/apptainer/apptainer.conf. This package will not be promoted to the epel repository for at least two weeks, pending approval by the EPEL Steering Committee according to the EPEL incompatible change policy. Apptainer 1.1.8 release notes are at https://github.com/apptainer/apptainer/releases/tag/v1.1.8 Dave

1 1

Retiring flintqs in EPEL7/8/9
by Ben Beasley 17 Apr '23

17 Apr '23

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_s… [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

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

epel-announce April 2023