Upcoming removal of rust2rpm + major Rust packaging toolchain update for EPEL 9
by Fabio Valentini
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
1 year, 1 month
Incompatible change in apptainer-suid-1.1.8 now in epel-testing
by Dave Dykstra
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...
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 year, 1 month
Retiring flintqs in EPEL7/8/9
by Ben Beasley
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...
[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 year, 2 months