On Tue, Feb 8, 2022 at 2:25 AM Ingvar Hagelund via epel-devel <epel-devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
Varnish is a web cache. It is extremely fast, reliable, modern, and
programmable. It may also be used as a level-7 router or swiss army
knife.
I maintain the varnish package in Fedora and EPEL.
epel7 has varnish-4.0.5. The varnish-4.0.x branch reached end of life
in 2017. Current supported LTS version of varnish is 6.0.x, which Red
Hat has adopted for el8, and probably el9 too. The latest 7.0.x is in
rawhide.
There is a security vulnerability
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23959 in all
previous versions of varnish. It is fixed in the latest releases
(6.0.10, 6.6.2, 7.0.2), see
https://varnish-cache.org/security/VSV00008.html . Red Hat has
classified their security update for el8 as "Important",
https://access.redhat.com/errata/RHSA-2022:0418 .
Upstream has not shown any interest in supporting the EOLed 4.0 branch
of Varnish, and backporting the fix to 4.0.5 is non-trivial, as much of
that part of the code has been changed and rearranged since 4.0 was
active.
There does exist a mitigation (with a performance hit) that may be
added by the varnish configuration language (VCL), see the VSV00008
page for details. It seems to work also for varnish-4.0. At least, the
mitigation VCL snippet compiles on varnish-4.0.5.
Providing security for EPEL7 users:
* Force mitigation:
It will be very difficult, not to say impossible, to automatically
enforce the mitigation in VCL. A valid VCL configuration may be split
over many files, and is compiled in the order it is read. Doing tricks
like adding the mitigation in an extra VCL file may break working
setups.
* Provide a new package with the current LTS version:
One solution may be to provide a new package "varnish60" or similar,
and in some way giving users a warning if they continue using varnish-
4.0, pushing them towards the new package and documentation.
* Upgrade varnish to the current 6.0.x LTS
This will break the rule about keeping the API/ABI stable
ABI: It is possible to build external binary compiled varnish modules
(vmods) that are loaded into varnish via VCL. They are closely bound to
the varnish version, so any vmod that is built for a particular version
of varnish must be rebuilt for another. There are ABI changes from 4.0
to 6.0, so any custom built vmods may have to be refactored to match
the new ABI. I have not found any vmods in epel7, though there exists
external repos that does this, for example my own
https://copr.fedorainfracloud.org/coprs/ingvar/varnish40/packages/
API: Varnish' configuration language VCL is versioned. varnish-4.0.x
supports VCL version 4.0. Varnish-6.0.x LTS uses VCL-4.1 by default,
but does support 4.0, possibly with a few changes. Upgrading should be
quite easy for most users. Many setups will just work without changes.
But it is not trivial as in "may be automated by a script". Or perhaps
it is? To test properly this would need a lot of varnish-4.0 users to
volunteer to test.
I'd like EPEL's advice on how to proceed on this.
br,
Ingvar Hagelund
Deciding which course does the least harm is hard, and ultimately it will be up to you, the maintainer.
If it was up to me, I would follow the procedure for breaking the API and update it to the version that is in RHEL8.
Why would I choose this?
1 - Package dependency
Looking through the epel repo's, it looks like there is only one package that would need to be rebuilt, collectd. And it looks like collectd still compiles fine on epel7.2 - Impact of an upgrade.
Since Varnish-6.0.x does support the VCL 4.0 version, the amount of end users that will have to make changes is smaller. I'm sure there are those edge cases, but those hopefully will be few.
3 - Supportability.
If you jump to the RHEL8 version, or possibly even the RHEL9 version, then you know the version will be supported for the rest of the epel7 lifetime. It will make your supporting the package much easier.
As for approval of the EPEL Steering Committee, it looks like you've already done a good investigation and looked at the various ways to solve it. If you decide to go with breaking the API, I'm confident that it will pass the committee vote.
Troy
_______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
