Hello, everyone
The Fedora EPEL SIG is asking for feedback to improve EPEL via this survey!
* https://fedoraproject.limequery.com/2023
The survey is targeting EPEL users and contributors. It asks about
how you use EPEL, how you contribute to it, and on what would you need
to improve that experience.
If you're someone who uses or works on Extra Packages for Enterprise Linux,
please participate. Survey closes at the end of September!
Thank you for your contribution!
I am performing an incompatible upgrade of the caddy package in EPEL
9. In accordance with the incompatible upgrade policy [0], I proposed
this upgrade just over a week ago on the epel-devel mailing list [1].
For reasons detailed in the previous email, it is no longer possible
to update the package at the current version, preventing me from
resolving known CVEs. Today the EPEL Steering Committee voted to
approve this upgrade [2].
This upgrade will take the package from version 2.4.6 to 2.6.4. This
includes a few backwards-incompatible changes. I believe these
changes are on the milder side, and most users shouldn't notice a
difference. Here are the most notable removals/changes:
- Reverse proxy: Incoming X-Forwarded-* headers will no longer be
automatically trusted, to prevent spoofing.
- Logging: Removed the deprecated common_log field from HTTP access
logs, and the single_field encoder.
- Logging: The remote_addr field has been replaced by remote_ip and
remote_port fields in HTTP access logs, which split up the two parts
of the remote address.
- Caddyfile: The reverse_proxy directive's handle_response
subdirective has had its status replacement functionality moved to a
new replace_status subdirective.
There are also a few additional changes to features labeled as
experimental, and some deprecations (not yet removed). For a full
list, see the upstream release notes [3][4].
If you are able, please test and provide karma for the update [5].
[0] https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/
[1] https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraprojec…
[2] https://meetbot.fedoraproject.org/fedora-meeting/2023-08-23/epel.2023-08-23…
[3] https://github.com/caddyserver/caddy/releases/tag/v2.5.0
[4] https://github.com/caddyserver/caddy/releases/tag/v2.6.0
[5] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-8849a14e7f
--
Carl George
I am retiring the caddy package from EPEL 7. In accordance with the
retirement policy [0], I proposed this retirement just over a week ago
on the epel-devel mailing list [1]. For reasons detailed in the
previous email, it is no longer possible to update the package with
the same major version, preventing me from resolving known CVEs.
Doing an incompatible update to the next major version is not an
appealing option with only ten months left until the retirement of
EPEL 7 as a whole.
Users that wish to keep using caddy on RHEL 7 can use the Copr repo
from the upstream project [2][3]. Caddy is also available from EPEL 8
and EPEL 9 for users that are ready to migrate to a newer operating
system version. Both of these options will involve the disruptive
update from caddy v1 to v2, but users can opt-in to it at their own
pace. The upstream project has a migration guide in their
documentation to help [4].
[0] https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/#process_s…
[1] https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraprojec…
[2] https://caddyserver.com/docs/install#fedora-redhat-centos
[3] https://copr.fedorainfracloud.org/coprs/g/caddy/caddy/
[4] https://caddyserver.com/docs/v2-upgrade
--
Carl George
golang-1.19.6 is now available in epel-testing for EPEL7, an update of a
minor version from 1.18.9. I expect it to be promoted in about a week
unless karma changes that.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-ba899b9717
My policy for updating golang in EPEL7 is to follow the updates in RHEL8,
including whatever patches they include. RHEL 8.8 released yesterday
updated to golang-1.19.6.
Dave
Hello EPEL users and developers,
RHEL 8.8 was released yesterday,
so I have updated ansible in EPEL 8 from 6.3.0 to 7.2.0 to match RHEL
8.8's ansible-core bump from 2.13.3 to 2.14.2.
Each ansible major version is tied to a specific major version of
ansible-core, and we keep them in sync.
Along with this change, RHEL 8.8 builds ansible-core for the python3.11
stack instead of the python39 stack that it was previously built for.
Therefore, ansible in EPEL 8 is now built for python3.11 as well.
I also updated ansible-collection-community-general to 7.0.0 as per the
discussions in [1].
Here is the Bodhi update: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-ca07fe358c
Please help test and give karma.
Until this update is pushed to stable, you may receive an error like
this when running dnf upgrade
```
Error:
Problem: package ansible-6.3.0-2.el8.1.noarch requires python3.9dist(ansible-core) >= 2.13.3, but none of the providers can be installed
- cannot install both ansible-core-2.14.2-3.el8.x86_64 and ansible-core-2.13.3-2.el8_7.x86_64
- cannot install both ansible-core-2.14.2-3.el8.x86_64 and ansible-core-2.13.3-1.el8.x86_64
- cannot install the best update candidate for package ansible-core-2.13.3-2.el8_7.x86_64
- cannot install the best update candidate for package ansible-6.3.0-2.el8.1.noarch
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
```
There are a couple potential solutions:
1. Run
$ dnf upgrade --exclude ansible-core
to skip ansible-core and upgrade everything else.
2. Later today or tomorrow, you'll be able to install
ansible 7.2.0 from testing with
$ dnf upgrade --refresh --enablerepo=epel-testing ansible ansible-core
and then run a plain `dnf upgrade` as usual.
Note that EPEL tracks RHEL and not rebuilds. Some rebuilds may lag
behind RHEL and not yet have 8.8 content. Our goal is to get packages
out as soon as possible so we don't break updates for RHEL users.
[1] https://lists.fedoraproject.org/archives/search?q=A+coordinated+plan+for+an…
--
Happy automating,
Maxwell G (@gotmax23)
Pronouns: He/They
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/1https://src.fedoraproject.org/rpms/rust-packaging/pull-request/6https://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
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
Hello EPEL users and developers,
RHEL 9.2 was released today,
so I have updated ansible in EPEL 9 from 6.3.0 to 7.2.0 to match RHEL
9.2's ansible-core bump from 2.13.3 to 2.14.2.
Each ansible major version is tied to a specific major version of
ansible-core, and we keep them in sync.
Along with this change, RHEL 9.2 builds ansible-core for the python3.11
stack instead of the default python3 (3.9) stack.
Therefore, ansible in EPEL now built for python3.11 as well.
Here is the Bodhi update: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-f51a0ff8a1
Please help test and give karma.
Until this update is pushed to stable, you may receive an error like
this when running dnf upgrade
```
Error:
Problem: package ansible-6.3.0-2.el9.noarch requires python3.9dist(ansible-core) >= 2.13.3, but none of the providers can be installed
- cannot install both ansible-core-2.14.2-4.el9.x86_64 and ansible-core-2.13.3-2.el9_1.x86_64
- cannot install both ansible-core-2.14.2-4.el9.x86_64 and ansible-core-2.13.3-1.el9.x86_64
- cannot install the best update candidate for package ansible-core-2.13.3-2.el9_1.x86_64
- cannot install the best update candidate for package ansible-6.3.0-2.el9.noarch
(try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
```
There are a couple potential solutions:
1. Run
$ dnf upgrade --exclude ansible-core
to skip ansible-core and upgrade everything else.
2. In a couple hours from from now (now is 3:15 UTC), you'll be able to install
ansible 7.2.0 from testing with
$ dnf upgrade --refresh --enablerepo=epel-testing ansible ansible-core
and then run a plain `dnf upgrade` as usual.
--
Happy automating,
Maxwell G (@gotmax23)
Pronouns: He/They
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