PHP constraint prevents security update

[dpagini]

Description

I realize that PHP 7.4 is out of support now, but unfortunately my project is still running on that platform. I'm running apigee_edge 2.0.6 right now, and I'm now unable to update to 2.0.8 which addresses a security vulnerability, b/c of the platform constraint in the composer file.
I added a similar comment here. It seems to me that removing PHP 7.4 support should not be a patch release item in semantic versioning. I'm wondering if the project NEEDS to specify PHP8 (was something added that doesn't work?). Can it not just be agnostic of PHP version, and only fully support (via tests) the latest versions of PHP?

[phdhiren]

@dpagini
PHP 7.4 was not actively supported from Nov'21 and now security updates are also not maintained from Nov'22 and already EOL.
https://www.php.net/supported-versions.php

I would strongly recommend you to upgrade to PHP 8.1

[dpagini]

I totally understand that... but now I have to upgrade my entire platform to 8+ in order to get a security release. There are other reasons blocking us from moving up to 8 immediately, but now I can't get a security release here. I definitely understand the project not supporting PHP7 anymore, but does it really have to say you can't use this module without the latest PHP? I guess what I'm asking is, can you leave your composer file alone, and just drop support via your testing? Does your project need to specify a PHP version at all in the composer file?

[dpagini]

Ok, I think I'm able to get around this with...

$ composer update drupal/apigee_edge --ignore-platform-reqs=php

Will need to test to see if anything breaks with an older PHP version... unless you know of anything that required the update? I can close this issue if you'd like?

[dpagini]

Hmm.. this lets me pull in the package, but it won't build for me on my CI servers without also changing those to ignore the platform requirements. =/

[phdhiren]

Right, you can consider changing those ignore platform requirements. Closing the issue here for now.

[dpagini]

I have at least 100 different Drupal packages and this is the only one that has dropped a major version of PHP support in a patch release. I really think you should reconsider how you're using/supporting semantic versioning.

[giteshk]

@dpagini thank you for bringing this to our attention.
We are evaluating our versioning approach and will update this thread shortly.

[phdhiren]

@dpagini

We will have PHP 7.4 in 2.0.[x] releases. And we'll be having 2.1.[x] where PHP 7.4 will be dropped. That will be maintained for the way forward.

[mxr576]

Please allow me to share my might be unpopular option here and ask rolling back all those changes that restored PHP 7 support before they end up in a public release (2.0.9 is already out :-( ) .

We are working with many Apigee customers and we did careful analyses of the ecosystem before we made the same step as the Apigee Edge module did before by dropping PHP 7 support. Even RedHat customers can upgrade to PHP 8.0 at least, but setting a minimum PHP 8.1 requirement in our product also did not cause any problem to our customers (and a considerable amount of them is also an Apigee customer) because they understood the clear benefit of skipping one release of PHP that soon to be EOL again. S

If anybody runs a PHP application on an unsupported PHP version than their primary security concern MUST BE that. Those who are running on outdated versions can still install PHP app/library security updates via Composer Patches, either by applying them from pull requests/commits or building their own custom patches.

Apigee could have a clear overview about all PHP versions used by Apigee customers who are using Apigee public cloud services if the special crafted user agent string would contain that information.

Does your project need to specify a PHP version at all in the composer file?

YES, every PHP application MUST specify clearly the minimum and the maximum PHP version that it supports and had been tested on. This is the only way to use Composer (the package manager) properly because that is one of the most important meta information that the package manager can use when it decides which version it installs from a package.