Problem/Motivation

Many software programs (including CMS software such as WordPress) support automatic updates, in which the site applies an update on its own with no intervention from the site administrator.

We need to continue exploring this for Drupal. Here are some pros and cons identified in this and related feature requests:

Pros

Cons

Implementing automatic updates means substantial new code of nontrivial complexity. There is no way to guarantee that the new code will not itself have security vulnerabilities. From the original issue summary, "The risks of introducing automatic updates to Drupal are that we don't want to open up new security holes in the process." Counter-argument: But can anyone argue that the net effect of the advent of automatic updates in other software has been decreased security? Automatic updates have been done, and done successfully, in many ways by many vendors with positive results.

A case is repeatedly made that it would require the site to be able to write to its own executable areas, and that this is by definition less secure. Counter-argument 1: A number of implementation strategies have been suggested that would not require the site to directly write to its own executable areas. In one, favorable hosting environments would install purpose-built software running in a separate process from the site itself to verify and perform the update. For generic hosting environments that offer authenticated (s)ftp/ssh as the means to change code, site owners could choose to provide the update infrastructure with valid credentials ahead of time; these could be retained in an encrypted database whose private key is offline 99% of the time (attribution). Credentials would then be supplied back to the site (an encrypted channel may be achievable for this purpose through native php code) and kept in memory during an update event. For sites that have been configured such that they can write to their own executable areas, "automatic security upgrades on systems with an already weakened security is a good idea. One might argue that every bit helps." (attribution)

It is a feature primarily targeting users with a low technical level, and they are not going to turn it on anyway (attribution). Counter-argument: If you're smart enough to build the rest of the site, then you can make the decision that is right for you whether or not you wish to turn it on. If your site was built for you, the firm who did so is smart enough to turn it on when continuing support is not part of the agreement -- an option they don't currently even have. These assertions won't hold true all the time for all people, but that's not a reason for Drupal not to offer this feature.

"Assuming that the low technical level users do enable the feature, the very first time that using it "breaks" their site, either by forcing it into maintenance mode or by performing an update which causes issues with some functionality in the site, they will either start to resent the Drupal project or turn the auto-update functionality off." (attribution) Counter-argument 1: The testing and review in place is sufficient that even if a less-conservative strategy is selected regarding the scope of code changes pushed automatically (ie, force sites to take feature releases when not at security release - 1), it will at worst break some sites and cause resentment for some people, and even that's not likely to be a regular occurrence. In the current state of affairs, all sites have a right to resent Drupal equally for its regular need to be manually updated, sometimes at inhumane hours of the day. Counter-argument 2: Fixes to security vulnerabilities rarely require large-scale refactorings or other changes that pose a high risk of site breakage. The infamous example need not be named yet again. Drupal has an opportunity to decide to do better than WordPress and use the automatic update facility to backport and distribute critical fixes. Combined with the testing and review mechanisms in place, site breakage could become a very minor concern.

There are concerns that the infrastructure that is used for distributing updates to sites would become "the biggest, fattest target ever for hacking. Just hack your way to there and suddenly you can hack a million sites in one go!" (Attribution) Counter-argument: This risk can be designed away by a good implementation. An implementation that merely serves up signed packages, probably Phar archives, that were signed using a private key on an airgap system nullifies this concern.

"My main concern would be with Version control systems and how would the updates be applies and tracked there." (Attribution) Counter-argument: If you use version control, you're not the target audience, at least for an initial version of this feature. However, if the design keeps the distribution and deployment components decoupled, advanced users would be free to contribute additional modules to handle deployment to all these scenarios.

it's been mentioned twice in this thread that popular contrib modules with an equally severe issue could also benefit from a system like the one being proposed. The question becomes, where do we draw the line? (Attribution) Counter-argument 1: This is a policy issue, and shouldn't derail the development of the automatic update technology. If a system was in place, there are some clear and appropriate uses for it that everyone can agree to. Counter-argument 2: Site owners already choose which modules they trust on their sites, and if the system were used to push contrib updates as well, site owners could take that into consideration in the modules they select (or, potentially, allow to be auto-updated). When the software is free, the user accepts the risk of possible defects. Making updates available automatically wouldn't need to fundamentally change the relationship between the security team and module maintainers.

But the patch might not apply... Counter-argument: What to do in the event of an attempted update that fails should be made configurable by the site owner, with the option to kill the site completely. This solution is discussed repeatedly, one attribution.



Proposed resolution

Implement a system to allow automatic background updates in Drupal.

It could be related to the current Update Manager functionality, but would likely need to be different because:

At least at first, we wouldn't want to use it on every security update, just a select few, and

We might want it to support patches (that apply against older releases as well, as was the case with SA-CORE-2014-005) rather than or in addition to actual version updates.

Security considerations

The risks of introducing automatic updates to Drupal are that we don't want to open up new security holes in the process.

Remaining tasks

Investigate how other systems implement this, including WordPress (see http://codex.wordpress.org/Configuring_Automatic_Background_Updates) see #82.

Decide if it's a good idea for Drupal and flesh out the plan.

Implement it.

User interface changes

There would likely have to be some kind of user interface to inform an administrator when automatic updates have run, or attempted to run but failed. There would have to be some method to turn this off for sites that absolutely don't want the functionality.

API changes

This would not be likely to involve any API changes, although certainly API additions. If approved and implemented, I see no reason it couldn't go in both Drupal 8 and Drupal 7.