Per policy [0], this is an announcement that I intend to retire the
caddy package in EPEL 7.
This package is in a bit of a weird state. The version in the EPEL 7
repo is currently 1.0.3, which was released upstream on 2019-08-14.
Upstream development on v1 stopped with the release of 1.0.5 on
2020-02-28. Recently I updated the package from 1.0.3 to 1.0.5 to
bring it as current as possible without breaking changes. At the same
time I updated a bundled library to resolve CVE-2022-3064 [1], and
also expected that rebuilding it with a newer golang would resolve
CVE-2022-41717 [2]. I published this update [3] to the testing repo
with the intention of testing it myself, but life got in the way and
it was promoted to stable before I had a chance to. I also forgot
that while I had enabled the test suite in Fedora, I did not have it
enabled in the epel7 branch. Unfortunately, I discovered that the
binary in this package would core dump immediately and was completely
non-functional.
As a quick partial mitigation, I asked RelEng to untag the broken
build to revert the repository back to the previous build [4]. After
investigating the problem, and consulting with upstream, I believe
that it is simply not possible to build a working caddy v1 binary with
golang 1.19 (the version currently available EPEL 7). Caddy is rather
sensitive to the version of golang that it is built with, both for the
minimum version, and as I discovered during this ordeal, the maximum
version as well. I considered doing an incompatible update to bring
the EPEL 7 package to a version of caddy that works with golang 1.19,
but ultimately decided against it. It would be a very disruptive
incompatible update because the config file format changed drastically
between v1 and v2. With a mere ten months left before EPEL 7's
retirement, I do not believe it is worth the effort or disruption to
do such an incompatible update. Due to the outstanding CVEs, and the
inability to even rebuild the package, I think the best course of
action is to just retire it. Per policy, I will take this action in
one week.
As an alternative, the upstream project maintains a Copr repository
[5][6] that provides the latest version, even for RHEL 7. This will
still be a disruptive update from caddy v1 to v2, but users can opt-in
to it at their own pace if they are unable/unwilling to migrate away
from RHEL 7 yet. Caddy is also available in EPEL 9, and will be
available in EPEL 8 soon [7], so upgrading to RHEL 8 or 9 is another
possible route if users are ready to migrate their OS.
[0]
https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/#process_security_reasons
[1] https://nvd.nist.gov/vuln/detail/CVE-2022-3064
[2] https://nvd.nist.gov/vuln/detail/CVE-2022-41717
[3] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-284c34a6cc
[4] https://pagure.io/releng/issue/11606
[5] https://caddyserver.com/docs/install#fedora-redhat-centos
[6] https://copr.fedorainfracloud.org/coprs/g/caddy/caddy/
[7] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-0b57e19163
--
Carl George
___
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
