php80: mark as broken on 23.11 #236904
php80: mark as broken on 23.11 #236904
Conversation
Atemu
requested review from
jtojnar,
aanderse,
etu,
globin,
Ma27 and
talyz
as code owners
github-actions
bot
added
6.topic: nixos
ofborg
bot
added
10.rebuild-darwin: 0
| @@ -337,6 +337,7 @@ let | |||
| maintainers = teams.php.members; | |||
| platforms = platforms.all; | |||
| outputsToInstall = [ "out" "dev" ]; | |||
| broken = (versionOlder version "8.1") && (isInOldestRelease 2305); # Will automatically break php < 8.0 with 23.11 | |||
There was a problem hiding this comment.
As discussed in #224505, I do not think this is correct. PHP itself is not broken.
There was a problem hiding this comment.
Why not? I thought PHP 8.0 is going EOL and therefore no longer supported by us come November?
There was a problem hiding this comment.
PHP 8.0 will be removed completely by then (preparing the PR to do that is in my todo list for next week).
What purpose does it serve to mark it as broken now?
There was a problem hiding this comment.
I wouldn't flat out remove in but rather mark it as broken/insecure. That way you can still opt into using dependant packages on your own risk.
The maintenance burden for a (marked broken) php80 should be close to nil.
There was a problem hiding this comment.
At the same time, nixpkgs isn't a collection of unmaintained or insecure software. Sooner or later it will become a huge maintenance burden when some dependency is updated that the old version of PHP won't support. Should we then override and pin older versions of everything there?
So no, we'll drop the old version that will become EOL from unstable early in the release cycle so we have time to find out what's broken and attempt to patch it before the next release, or just mark it as broken by then during the ZHF process.
There was a problem hiding this comment.
Sooner or later it will become a huge maintenance burden when some dependency is updated that the old version of PHP won't support.
At that point, you'd simply remove that old, deprecated version of PHP. It will have likely been marked as broken/insecure for a while by then, so nobody can complain they weren't warned.
As you correctly stated, we're not a collection of unmaintained or insecure software. No support is guaranteed here. What I'm concerned about however is to keep those deprecated versions around until they actually cause real issues. As long as they do not cause real issues, they do not hurt us.
I wouldn't advocate for keeping it if there were no users but in this case we do have significant users within Nixpkgs. We're even using limesurvey right now for this year's community survey.
just mark it as broken by then during the ZHF process
This is effectively what my PR does. On branch-off, php80 will "automatically" be marked as broken. No 23.11 user can build a system with php80 without explicitly allowing the package.
There was a problem hiding this comment.
The fact we were not able to remove PHP 8.0 entirely for 23.05 is already less than ideal: PHP 8.0 security supports ends a bit before the sunset of 23.05.
I'm still not sure to understand what's the point of marking PHP 8.0 as broken right now? It is likely to confuse users as they will end up compiling the package instead of pulling it from the binary cache and there is no easy way to understand why. PHP 8.0 can still be built and installed with no issues which is what meta.broken is about.
I wouldn't advocate for keeping it if there were no users but in this case we do have significant users within Nixpkgs. We're even using limesurvey right now for this year's community survey.
PHP 8.1 was released 1.5 year ago, if upstream cannot keep up with PHP releases resources are probably best spent on working to help them with the compat issues instead of trying to keep it in a somewhat working state in nixpkgs that will ultimately be insecure.
For Limesurvey since bc48fa8 the 6.x version was released and it supports PHP 8.1.
https://manual.limesurvey.org/LimeSurvey_roadmap#LimeSurvey_6.0
https://manual.limesurvey.org/index.php?title=Installation_-_LimeSurvey_CE&type=revision&diff=176140&oldid=175637
There was a problem hiding this comment.
The fact we were not able to remove PHP 8.0 entirely for 23.05 is already less than ideal: PHP 8.0 security supports ends a bit before the sunset of 23.05.
Agreed.
I'm still not sure to understand what's the point of marking PHP 8.0 as broken right now?
Again, it won't mark it as broken just yet. It will be marked broken once the next release maintainer bumps the version before branch-off which, in this case, should be right around the time it goes EOL anyways.
It is likely to confuse users as they will end up compiling the package instead of pulling it from the binary cache and there is no easy way to understand why.
Agreed. Though until we have a better way to do this, this is how it's done unfortunately.
Another way to do it would be to keep it unbroken but start adding CVEs as they come in; marking the package as insecure. I don't really like this option because it'd communicate to the user that php80 is still supported and the expectation of supported software on a stable release is to stay supported, which it won't. Also maintenance burden.
An alternative that I have thought of/discovered just now would be to treat it like openssl_1_1; add a pseudo vulnerability:
nixpkgs/pkgs/development/libraries/openssl/default.nix
Lines 236 to 238 in c66b67f
Since there's precedent for this in Nixpkgs, would you be fine with that?
PHP 8.1 was released 1.5 year ago, if upstream cannot keep up with PHP releases resources are probably best spent on working to help them with the compat issues instead
This is the best solution. I wish it was an option. Nobody should use or support EOL software.
Grocy upstream is not very cooperative and does not see any issue.
They've got 8.1 support in their dev branch but I wouldn't be comfortable shipping it. I have no idea about PHP, so I couldn't do a backport either.
For Limesurvey since bc48fa8 the 6.x version was released and it supports PHP 8.1.
Great!
This reverts commit 314c64c.
Atemu
force-pushed
the
php8.0-mark-unsupported
branch
from
f511780
to
3057c6c
Compare
|
PHP 8.0 has been removed :/ |
|
We'll still maintain it in the stable branch until EOL.
…On Sun, Jun 25, 2023, 17:59 Atemu ***@***.***> wrote:
PHP 8.0 has been removed :/
—
Reply to this email directly, view it on GitHub
<#236904 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADQZEWTSBBKIAFWMX4HHOLXNBN5PANCNFSM6AAAAAAZA7QIBY>
.
You are receiving this because your review was requested.Message ID:
***@***.***>
|
Description of changes
Things done
sandbox = trueset innix.conf? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)