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:
- Users want it. Some have found that it is worth leaving the platform for easier/cheaper to maintain alternatives.
- It would be particularly useful for situations like SA-CORE-2014-005/PSA-2014-003 (very low-risk patch for a very critical security issue where speed is of the essence).
- It would go a long way to improving the overall security of Drupal installations across the internet: the reality is many sites just go un-updated under the current manual processes. As a platform powering better than a million websites, it is the "good netizen" thing to do -- every site that doesn't get compromised translates to many outdated browsers not getting exploited, and personal computers not getting hacked.
- Given the larger codebase and use of external libraries in Drupal 8, manually applying fixes is likely to become more frequent and on a less predictable schedule, making automatic updates even more valuable.
- 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), broken sites are much easier and cheaper to fix with confidence than compromised sites. Accepting some risk of breakage is therefore the preferred model of a segment of the userbase (additional attribution). Organizations running sites that secure billing and other confidential information may similarly find this risk model preferable.
- It would not be forced on anybody. It would only empower site owners to choose whether it is the right solution for them. It could be built as a highly isolated module that can be disabled completely, which would make an exploit of the automatic update system itself very implausible on sites that don't think it is right for them.
- Without some form of automated security update solution in place, I fear I may never be allowed to take a holiday again...(attr.)
- 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 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.
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.
The risks of introducing automatic updates to Drupal are that we don't want to open up new security holes in the process.
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.
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.
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.