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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
