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 _______________________________________________ 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
