Automatic Updates

Updating a Drupal site is difficult, time-consuming, and expensive. It is a tricky problem that, on its face appears easy, however, ensuring secure and reliable updates that give assurance to site owners and availability to site visitors.

The Automatic Update service for Drupal aims to simplify this process and provide confidence that an update will apply cleanly.

Key Features of the Automatic Updates Module

Public service announcements (PSAs)

Announcements for highly critical security releases for core and contrib modules are done infrequently. When a PSA is released, site owners should review their sites to verify they are up to date with the latest releases and the site is in a good state to quickly update once the fixes are provided to the community.

Update readiness checks

Not all sites are able to always update. The readiness checks are an automated method to determine if a site is ready for automatically updating once a new release is provided to the community. For example, sites that have un-run database updates, are mounted on read only filesystems or do not have sufficient disk space to update in-place can't receive automatic updates. If your site is failing readiness checks and a PSA is released, it is important to resolve the underlying readiness issues so the site can quickly be updated.

In-Place Updates

Once the PSA service has notified a Drupal site owner of an available update, and the readiness checks have confirmed that the site is ready to be updated, the Automatic Update service can then apply the update. 

Installation

To install the contrib version of the Automatic Updates module, you will follow the same instructions that you would use for any other module on Drupal.org:

1. Download the appropriate release from https://drupal.org/project/automatic_updates

2. Install the module manually

OR

1. If you are a drush user, run the command: 

$ drush pm-enable automatic_updates 

Use of the Module

Attended Use

The PSA feature will display a Drupal.org served PSA directly in the Drupal admin interface, to notify users of an upcoming release.

The Readiness check feature will run regularly to ensure that there are no problems that would prevent an update from applying.

On the module configuration page, a user can choose to manually trigger the in-place update.

Unattended Use

To enable unattended updates, simply check the box on the module configuration page allowing updates to be run on cron. Updates will only be applied if the site is passing it's readiness checks.

Architecture of the Automatic Updates System

Core Features

Public Service Announcements (PSAs) 

The Public Service announcements are architected by consuming the provided PSA.json feed from Drupal.org and displaying the results with a simple drupal_set_message() 

Readiness Checks

The readiness checks are a pluggable system allowing a variety of different types of checks to be run, and warnings or errors to be displayed in the Drupal admin interface. 

In-Place Updates

In place updates are architected using hashed and signed 'quasi-patches' generated by Drupal.org. These quasi-patches are verified using the php-libsodium library, which is available and backported to PHP version 5.3.

Once verified, the quasi-patch is applied with the PHP copy function - simply overwriting all of the files changed in the update.

Test Features

In the current version of the Automatic Updates module, the user can enable a test version of the Drupal.org PSA json feed, allowing you to see how the PSA information will be displayed.

To do so: 

1. Enable the automatic_updates_test module using the Drupal module administrative interface, or using the command: 

$ drush pm-enable automatic_updates_test

1. Set the variable to enable the test feed, by using the command:

$ drush vset automatic_updates_psa_endpoint http://localhost/automatic_updates/test-json

    If you build your own test feed, you can substitute the url to your test feed with this command.

To set the feed back to the Drupal.org official PSA feed:

1. Run command 

$ drush vset automatic_updates_psa_endpoint https://updates.drupal.org/psa.json

1. And disable the automatic_updates_test module, either using the Drupal module administrative interface, or by running the command: 

$ drush pm-disable automatic_updates_test

Drupal.org Infrastructure

Automatic Updates for Drupal are supported by the infrastructure of Drupal.org, and funded by the activities of the Drupal Association. 

Public Service Announcement(PSA) feed

Drupal.org provides a JSON feed of Drupal Public Security Announcements to be consumed by the automatic updates module.

The canonical URL for this feed is: https://updates.drupal.org/psa.json

That feed includes values for the following: 

• Project type (core, module, theme, etc) 

• Project: the shortname of the project the PSA is for

• Title: The title of the PSA

• Is_psa: The flag which indicates that the post is a PSA (and not another kind of Security Advisory) 

• Link: The link to the full PSA on drupal.org

• Insecure: Metadata about what versions of the affected project are known insecure

• pubDate: The date the PSA was published

For example, if this older PSA—https://www.drupal.org/psa-2019-05-07—were included in the PSA.json, the feed would appear as follows:

[
   {
      "type" : "module",
      "project" : "securitydrupalorg",
      "title" : "Drupal 7 and 8 release on May 8th, 2019 - PSA-2019-05-07",
      "is_psa" : "1",
      "link" : "https://www.drupal.org/psa-2019-05-07",
      "insecure" : [],
      "pubDate" : "2019-09-12T21:35:54+00:00"
   }
]

This feed is then parsed by the Automatic Updates module for display in the Drupal admin interface.  Other modules or services could also consume and display this feed.

More information about the PSA.json feed can be found in this issue: https://www.drupal.org/project/drupalorg/issues/3068539 

Package Generation

The Drupal.org packaging system is what produces the .tar.gz and .zip downloads of projects on Drupal.org. At the same time that this system runs, it also updates the Composer façade and, with the addition of this Automatic Update system generates the 'quasi-patches' that are used to update a site with the automatic_update module.

Package Signing and Security

To ensure that the 'quasi-patch' packages are secure and can be verified, Drupal.org uses a package hashing and signing architecture based on the BSD Signify project.

Drupal contributors have created a php implementation of signify, which is available on the Drupal github namespace: https://github.com/drupal/php-signify

This library is used to create SHA hashes of the files included in the project hash, which are then signed using a Public/Private key pair generated from an HSM in the Drupal.org infrastructure.

For more detail about how the hashing and signing system is being architected, please consult these issues: 

• https://www.drupal.org/project/automatic_updates/issues/3072104
• https://www.drupal.org/project/automatic_updates/issues/3071193
• https://www.drupal.org/project/automatic_updates/issues/3077737

Providing Feedback

To provide your feedback on this first generation of the Automatic Updates module, please create an issue in the Automatic Updates issue queue.