CentOS Stream seems to ship with PHP 8.0 as a “Base” (in lack of knowing a better term) which is end of life and out of security support. It is generally advised to not run such software versions and to make matters worse, PHP is usually exposed to the internet. In theory you could switch to a different version via modules, but that is impossible if you want to use a PHP module from EPEL which does not support modules.
Now I do have some questions in order to plan accordingly:
How is it justifiable from a security perspective to ship PHP 8.0 as a base or default version in CentOS Stream 9?
Are there any plans to upgrade this or will EPEL PHP modules be stuck with PHP 8.0 for the whole Stream 9 release cycle?
Will EPEL get support for modules in the foreseeable future?
Any other ideas or best practices on how to deal with this situation as an administrator?
PHP 8.0 is a full-life Application Stream in Red Hat Enterprise Linux 9, which means it will receive backports and security fixes for the whole lifecycle of RHEL and therefore the whole lifecycle of CentOS Stream 9. You can find more information about Application Stream lifecycles here:
That answers your question #1.
For question #2, select newer versions of PHP will be added with a shorter lifecycle throughout the life of the release. Currently PHP 8.1 is also available, for example. This isn’t an upgrade, but an additional version. I’m not entirely sure what the implications are for EPEL PHP packages.
For question #3, you would have to ask the EPEL project. The last information I have on this was that they were not going to support modularity.
On another thought PHP 8.0 still is an issue because the app I host will get upgrades and they will drop support vor PHP 8.0 in the C9S period. (They justify that by reminding me that it is EOL )
Any recommendations or experience on rebuilding a PHP module (imagick) for PHP 8.2? I’m thinking to try a local RPM build or to configure a copr build accordingly.
)