On the roadmap: deprecation of PHP 7.4

We would like to warn you that PHP 7.4 will be dropped for Nextcloud 26.

We would like you to understand why we made this decision and gather information for you about how to upgrade.

Why?

PHP communicated that support for security fixes for 7.4 will be stopped by end of November, 2022. This means that running PHP 7.4 will come with considerate security risks. Continuing to support PHP 7.4 means we cannot introduce new security measures that PHP 8.1 comes with. The syntax that we are allowed to use must be the lowest one of the supported versions, thus the upstream packages of third parties break because they dropped this support. Most of the packages drop support for old versions once those packages are no longer supported by PHP in general, and this is now the case.

Another important consideration is that running an old PHP version significantly affects performance. The language improved over time. For example, we use some parts of the symphony in the Nextcloud code. A PHP release blog wrote Symphony on PHP 7.4 takes roughly 1,6 seconds to answer 250 requests, and Symphony on PHP 8.1 takes roughly 1,2 seconds to answer 250 requests. Thus, the new version is roughly 24% faster.

This is why we decided to follow this and plan to drop the support for 7.4 too, to be able to prioritise security and performance and keep our technology stack up to date.

Manuals

For all recommended operating systems that do not already come with php 8.1 out of the box, manuals are available how to upgrade to php 8.1:

Ubuntu 22.04, and openSUSE Leap 15.4 / SUSE Linux Enterprise Server 15, already come with php 8.1 out of the box so we assume the deprecation of php 7.4 is not a blocker for those use cases.

Long term support needed?

Given manuals are available, we assume that all small scale installations are able to upgrade the php version without considerable blockers. We do think this can be a larger consideration for very large scale installations or service providers who run many instances and we have a solution for that.

If you are running Nextcloud for such an organisation-critical use case, you could consider upgrading your subscription to a premium subscription which comes with 5 years of long term support.

This means that you could run Nextcloud 25 for up to 5 years after the enterprise version release date, which means you could continue running php 7.4 until December 2027.

By that time, for example, the Ubuntu LTS stack would also no longer be supported anymore for 2 years, so we assume the deprecation of 7.4 within Nextcloud will no longer be a blocker for you.

Next steps

If you know other operating system manuals that can help people to upgrade, please let us know.

We added a section to our admin documentation about the support of old PHP versions as we expect this to be a repeating concern, given that new PHP versions are released and deprecated every year.

As we know this might be a difficult blocker for some of you, we want to be transparent about it and communicate early.

This is why we decided to already communicate about this now. Note that this is a 4-months notice period, given that Nextcloud 25 will of course continue to work on 7.4. If PHP 7.4 will be dropped for Nextcloud 26, then the admin settings in Nextcloud 25 will also show a warning.

All the best!
Daphne

Edit: updated the post with latest information from @Andy and the tutorial of @MichaIng

11 Likes

For debian users, it would be great if there was an upgrade path based on stable debian releases (without external php packages). The next debian release expected in 2023 (https://wiki.debian.org/DebianReleases) will include php 8.1 (https://wiki.debian.org/PHP).

Therefore, NC 25 support would need to be increased slightly in case NC 26 drops php 7.4 and debian is released later next year (to guarantee some overlap). I don’t know how much effort this would be but it would help a lot of less experienced users.

4 Likes

If this becomes a concern for Nextcloud 26 I will bring this up as a potential solution direction :+1:

2 Likes

@Daphne
I also think like @tflidd . I think with Nextcloud 26 Debian Bookworm is not stable yet. Also the operating system should have been stable for some time.

If you do not want support PHP 7.4, maybe you can write how to install PHP 8.1 correctly under Debian Bullseye (then still Stable).

Basically, the upgrade to Nextcloud 26 could then become problematic from Debian Bullseye with and without instruction.

I don’t know if I would rather switch to Debian Testing first to upgrade to Nextcloud 26 or vice versa to manually install PHP 8.1 in the old release to be able to switch to Nextcloud 26 and a few months later switch to Debian Bookworm and repair my PHP 8.1.

The most sensible recommendation would be simply not to switch from Nextcloud 25 to Nextcloud 26 and wait the months until the release of Debian Bookworm.

Here the links:
Debian Stable (Bullseye): PHP 7.4 link
Debian Testing (Bookworm): PHP 8.1 link

With Ubuntu no problem:
Ubuntu 22.04 LTS: PHP 8.1 link
old release: Ubuntu 20.04 LTS: PHP 7.4 link

I think there are still patches for Debian Bullseye. I would not consider that an argument against PHP 7.4 in Nextcloud 26. Hopefully the debian maintainers will take care of it.

I think it is not a long term support. It is the support for the normal stable repository of Debian Bullseye. Debian Bullseye LTS goes to 2026 Debian LTS. Acutal Debian Buster is LTS with PHP 7.3 link

I appreciate this advance :wink: communication…

little late in my eyes, I would have expected to see a deprecation notice for (most?) important EOL component much longer than 13 days before EOL, but I consider this as an improvement already compared to 32-bit support and other bad thing happened in the past.

I see the point with Debian and their (very appreciated) long support times - but I bet they could provide very limited support from their side once upstream project stops shipping security fixes…

I would appreciate Nextcloud provides clear statement and deprecates insecure PHP versions early (maybe as part of the release schedule).

Definitely there must be good good support e.g. migration guide for major platforms but especially for bigger installations and hosting providers I would expect they deprecate EOL software themself, rather looking for “long-term support”. In opposite to SOHO users they have power and know-how to perform an update… System lifecycle is daily business for every professional on this world and there is no good argument to expose EOL software to the internet.

1 Like

Many thanks for the timely communication :+1:.

From the sight as DietPi developer which wants to keep supporting an automated ready-to-use Nextcloud installation on our Debian-based OS, to often less experienced users:

  • Whatever you do, implement an update blocker, not just an admin panel warning. Pulling latest NC25.x based on distro/PHP version is simple, and security updates for NC25 are provided until after Debian Bookworm is released (August 2023 most likely).
  • About Ondrej’s PHP repo: For a single mid-to-high experienced admin, it is a nice solution. But implementing this automatically for the masses, done to preserve Nextcloud support on Debian Stretch that time, when PHP7.0/7.1/7.2 support was dropped, caused us a lot of long term trouble, and it still does, with conflicting DEB packages and by times difficult solutions since the repo ships edge versions of essential system libraries, which are not (automatically) overwritten on distro upgrades (Buster => Bullseye and such). And as the meta packages (php-fpm vs php8.1-fpm, not installed by our installer, but users do) are moving targets, regularly we saw users with multiple PHP versions installed and concurrent redundant/obsolete PHP-FPM services running, and broken PHP handlers when old versions are removed. So I’m never ever gonna implement this again :wink:.
    I.e. a guide covering this repo should make clear that one should know a bit about Debian packages, how webserver and PHP are setup, that explicit versioned packages should be installed etc, and/or be prepared to rebuild the system from scratch when larger package/distro upgrades cause mentioned issues. I can help with this, when someone does a start with such guide.
3 Likes

There will be an update blocker!

If you would be up for writing a guide we would be very grateful for your help here. I will drop you a 1:1 line to talk about it

3 Likes

Thanks for your insights on this.

In an ideal world you are right. But people and organizations have a variety of reasons why they don’t run the latest version and dismissing their realities might not be helpful. It is common to be blocked by a lack of resources (time, money, knowledge) and a need to prioritize is experienced. This is why we try to understand these dynamics and why I would like to encourage people to talk about their constraints. Maybe then we are able to come up with practical solutions like the ones earlier mentioned about the Debian release cycle.

2 Likes

I know the situation you describe… but there are too many evil actors on the internet who permanently try to attack and exploit vulnerable system. Today there is definitely no excuse to expose a system with end of support modules to the internet. I’m not a hardcore security fetishist who recommends to install patches immediately, I always recommend to wait a little before updating production but I always recommend everybody to install patches short after release as soon it looks almost stable. And here we talk about pre-previous version of a framework driving one of most important applications in your network… 7.4 was released 3 years ago and stopped active support 11 months ago… If you don’t find time to upgrade your system within this time frame maybe you become less busy when you system got hacked, vanished and all you data is on sale in the darknet…

3 Likes

I’m not sure I follow, how do you get 13 days? 7.4 support may be dropped in 26, which will not be out before several months.
If you want to know PHP versions EOL dates, please refer to the PHP project, which announces them several years in advance: PHP: Supported Versions

2 Likes

from the source you refer:

In my eyes support for 7.4 should have been dropped in NC25 NC23 or NC22 already as PHP 7.4 EOL date is known since long time…

Debian Bullseye Stable 11 uses PHP 7.4 link . It is still the Stable Debian release for all production Debian servers until middle of 2023. And then you can use Debian Bullseye OldStable one year and then Debian Bullseye LTS another year.

PHP 8.1 link is only in Debian Bookworm Testing/Sid 12. Of course you can always include PHP 8.1 as a third-party source.

This would have been way too agressive and would have made Nextcloud hard to install on a lot of setup.
There is no reason to drop support for PHP versions before they go EOL in my opinion.

2 Likes

this is absolutely true, but you should not only consider release date but also take into account EOL of the Nextcloud release as well. NC23 becomes EOL once NC26 is released, which is definitely far behind 7.4 EOL. There is no good reason to support an EOL framework in my opinion.

I have no idea how Debian plans to address security issues - the statement above applies there as well.

1 Like

They do backport security fixes: https://wiki.debian.org/PHP#Notes_on_PHP_and_security

But I’m using the Sury repo anyways, so when it comes to PHP, I’m not dependent on the Debian release cycles or any backports.

Btw. Those who do not want to include third party repos as a matter of principle should make an exception here. Ondrej Sury is also one of the maintainers of PHP in the Debian project. So I think he knows what he is doing. :wink:

8 Likes

Yes, but many distros—Ubuntu, for example—do indeed backport security fixes for 5 or 10 years. So the situation is not always as dire as you paint it here.

Therefore a middle ground may be desirable. I trust that Nextcloud will find the right balance as a project that is infamously fast-moving.

2 Likes

Here are the pull requests for removing php 7.4 support in Nextcloud 26 (or beyond).

4 Likes

yes they do. the question is how much they do. If you follow the Debians policy provided by bb77 you will find only very very bad security issues will be addressed by Debian (which is one of the most serious projects IMHO). this slightly improves to original 7.4 but it will never compare with the current actively maintained PHP version.

But the more important question is - should Nextcloud support outdated PHP and other dependencies (I would widen it to OS, database etc. as well) - I would strongly argue that they should not. Even further I would recommend align the end of support of specific component with NC roadmap - in this case PHP 7.4 should have been deprecated with the earliest NC version supported on 28. Nov 2022. I think it’s a good habit to mark components as “deprecated” once the upstream reports deprecation. It doesn’t mean you drop it completely but people need time to upgrade such important components as PHP - so deprecation notice 11 months ago would have been at right time - so Nextcloud could completely drop 7.4 support with NC24 - which is expected to remain supported until Spring 2023 - potentially running on insecure PHP version.

I really appreciate deprecation of PHP 7.4 now and I hope to see deprecation of PHP 8.0 soon - which stops active development in Jan 2023 - I would be disappointed to see PHP 8.0 support in NC26…

The question here is not only if it is secure enough for your system - support of specific libraries, requires additional testing, sometime additional code - early deprecation saves dev resources and allows admins to prepare. If admins decide to keep old versions - their choice, there are still people using Windows XP and connected with internet - but a vendor should never ever support a component without active security patches.

Just in case: who you would blame if some security bug in PHP results in successful Nextcloud instance hack?

1 Like

The hacker.

Next, probably the Linux vendor. But if I’m going to list a chain of entities at fault, Nextcloud is going to be pretty low on the list if it was just a fundamental flaw in PHP.