nextcloud / nextcloud/server

Disable long outdated Nextcloud instances

Open
#14,230 27 comments 3 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

1. to develop enhancement feature: activity and notification feature: install and update needs review overview
Dominant language
PHP
Stars
36.9k
Forks
5.2k
Avg merge
2d 3h
Merged PRs (30d)
713

Description

Is your feature request related to a problem? Please describe.

There are at least 8.000 instances out there that contact our updater server that have a version up to 13.0.0, 12.0.5, 11.0.7 or 10.0.6. All those versions have in common, that they were released more than a year ago. That means (except for 10.0.6, which was already end of life by then), that there was a minor release afterwards, that fixed something on that version - be it a normal misbehavior or a security bug.

As the main goal of Nextcloud is to be able to host your data on your on servers and that comes with a big plus in privacy there is the downside of the need to manage updates on your own. There is no privacy without security.

Describe the solution you'd like

The idea is to have a staged escalation of behavior of the Nextcloud instance which ends with the complete isolation - feature wise - after a given date. This might sound hard, but let me explain it in more detail.

With staged I mean that there are different steps to make the admins and users aware of the potential issue. The whole idea bases on the release date of the given version that currently runs.

Let me put here an example of how this could work:

  • 2018-03-15: release date of 13.0.1 that currently runs on this example instance
  • 2018-09-15: all users in the group admin (and the group specified in the update notification app) are notified (via push notifications and email) that it is recommended to update - otherwise all users are notified about this 1 month later
  • 2019-01-15: all users of the instance are notified that an update is recommended
  • 2019-02-15: all users are notified, that the instance will go into safety mode if no update happens within the next month
  • 2019-03-15: instances goes into safety mode

This safety mode means that the instance will not serve anything beside the login prompt that the admin can use to login (and only admins) to use the web updater to upgrade the instance. Maybe we just completely turn off the web UI with a nice warning and an update needs to be run manually.

Obviously the times are now just some example values, but 9 months for the admins, 10 months for all users, 11 months for all users with the warning of the safety mode and 12 months to trigger the safety mode seems to be a sane amount of time.

Describe alternatives you've considered

Currently there are already notifications about updates and updates are installed quite often, still there is a big amount of instances out there that runs really old software. Also as this is an open source product you could obviously patch out the check and run the software in an air gapped env for example for eternity.

Beside this it's just one part of many to increase the security of our product. There is also some vague plans to provide a reliable way to install security updates automatically, but this is something for a separate ticket.

Implementation details

The implementation would be quite straight forward. Add something like lib/versioncheck.php and one entry in version.php with the build date. Then calculate the current date and compare if the build date + 1 year is smaller than the current date. If this is hit we serve a static page like the maintenance page with more information. Nothing more. The notifications and other user facing stuff should be handled in another section to have no impact on the general load of every request.

@karlitschek @jospoortvliet @nickvergessen @blizzz @ChristophWurst @juliushaertl @skjnldsv @jancborchardt @rullzer Opinions? Is this a good idea or something totally horrible and total no-go?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

The proposal names a new lib/versioncheck.php and an entry in version.php; first inspect existing version, updater, notification, and maintenance-page handling. The staged notifications, release-date cutoff, and safety-mode behavior need maintainer agreement before implementation. Done means the behavior and scope are agreed and the resulting changes are covered by appropriate project checks.

Written by the indexing model from the issue text.

Assessment

Tech stack
php
Domain
backend, security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.