Automatic Updates Initiative overview and roadmap

Created on 30 January 2018, almost 7 years ago
Updated 2 July 2024, 5 months ago

Drupal 10 roadmap 🌱 Drupal 10 Core Roadmap for Automatic Updates Active

🌱 Drupal 10 Core Roadmap for Automatic Updates Active

Initiative Overview

The goal of the Automatic Updates Initiative is to provide safe, secure automatic updates for Drupal sites. This is an essential strategic initiative β†’ for Drupal 9 core for two reasons:

  1. Manually updating sites is difficult, time-consuming, and expensive, and the difficulty of updating Drupal is repeatedly raised as a top concern for using Drupal.

  2. Delays between the release of a security advisory and the deployment of the corresponding Drupal update result in a time window where sites are vulnerable to exploit. Many sites do not apply updates for 2-4 weeks after the release of a security advisory, and site owners who want to ensure the security of their site need to have site maintainers available during the 1200 EST security release window (which is in the middle of the night for much of the Eastern hemisphere).

Both these factors increase Drupal's cost of ownership and decrease user confidence in the platform.

How to get involved

Join the #autoupdates channel of the Drupal community Slack β†’ .

Meetings are held on the every other Tuesday at 1:00 PM EST in the #autoupdates channel. Minutes from past meetings and agendas for upcoming meetings can be found in the Automatic Updates project queue β†’ .

Work is currently going on in 4 projects:

  1. The 8.x-2.x branch of the Automatic Updates Contrib project. This work will be port to Drupal core directly. Issues to be worked on can be found in the issue queue for 8.x-2.x β†’
  2. The Github PHP-TUF library: this will ensure updates are correctly signed
  3. A Composer plugin to integrate PHP-TUF signing with Composer. This depends on drupal.org's packaging pipeline and Composer facade supporting PHP-TUF signing, which is being built under the supervision of the DA.
  4. The Github Composer Stager library: this library will enable Drupal core to stage updates before they are applied

Session recordings

Automatic Updates architectural spec/overview

Background: Personas

  • Deploy and Ignore: Once the site has the functionality needed, there's little maintenance or updating. Doesn't subscribe to PSAs.
  • Site owner who cares once a year: Deploy and ignore w/ an exception once a year
  • Diligent but with Simple Needs: Typically applies updates within a week of release, possibly longer for non-security updates. Follows up on PSAs by directly updating the live site.
  • The Sophisticate: Needs to apply at least one build step (for CSS, Composer, etc.). Runs QA in a pre-production environment. May deploy to a multi-head cluster.
  1. Validation, readiness checks and notifications

    The Automatic Updates module verifies that it is safe to apply an update to a site prior to downloading an update, and informs the site owner if updates cannot be installed automatically.

    The readiness check API is being developed in the 8.x-2.x branch of the contrib project β†’ . See #3230045: [Meta] Create validation listeners β†’

    The readiness checks include (but are not limited to) the following:

    • Is the site on the latest release of core?
    • Does the site codebase match the official release? (I.e., no patches applied, no hacks to core, etc.
    • Does the site have outstanding database updates?
    • Is there available disk space?
    • Are file permissions configured appropriately?
    • [Still needed / not yet added] Is the memory available sufficient for updates to be installed? Issue: ✨ Add a PHP Memory Readiness checker Needs work

    In addition to the readiness checks, we're also adding display of critical security Public Service Announcements on the Drupal site status report and administration pages: #3041885: Display relevant Security Advisories data for Drupal β†’ .

  2. Signing and verification

    Signing of Drupal releases will be handled according to The Update Framework (TUF) specification. drupal.org will provide signed versions for Drupal releases and vendor libraries that will be needed for updates.
    Core will use the PHP-TUF library which implements a client library. This library is currently being developed may be used by other PHP CMSes.

    The PHP-TUF client library will require Composer integration to verify the packages before they are installed via Composer. This is done by way of a plugin for Composer 2.1 or later: https://github.com/php-tuf/composer-integration. The plugin depends on TUF signing information being available for all requested packages, which is being added to drupal.org's packaging pipeline and Composer facade under the supervision of the Drupal Association.

  3. Staged update and rollback

    The update functionality in Drupal core will need attempt to run an update via Composer and be able to determine if the update succeeded. If the update was not successful the site should be left unaffected and in a working state. If the update was successful, the production site should switch to the new codebase with 0 or minimal maintenance mode window needed.

    An earlier proposal for this was ✨ Replace single index.php with a frontend controller that supports A/B updating (automatic updates) Active .

    However, we encountered some issues with that, and our current proposal is #3199171: Automatic updates: For MVP, instead of an a/b bootloader, implement a semi-atomic composer update with a brief maintenance-mode window β†’ .

  4. Update installation

Roadmap

[Complete!] Phase 1

Phase 1 included developing a Drupal 7 and 8 contributed module with readiness checks, security public service announcements, and in-place manual and automated updates for tarball-based sites.

[In progress] Phase 2 (Initial core requirements)

Phase 2 of the initiative is to add the initial requirements for automatic updates to Drupal 9 core. The initial core module will provide automatic updates for:

  • Core only
  • Composer-built sites only
  • Patch/security releases only
  • Updates for the installed minor version

Phase 2 requirements:

[Outline and issue list here, based on most recent meeting]

  1. Completed πŸŽ‰: Port PSA functionality to core system.module

    #3041885: Display relevant Security Advisories data for Drupal β†’

  2. Port the 2.x branch of the contrib module β†’ to core

    This will add two new modules to core: Automatic Updates (auto_updates) and Package Manager (package_manager). Package Manager provides the underlying API to create and manage a staging area in which to modify the Drupal code base, and will be used by the Project Browser β†’ module as well. Automatic Updates will implement the readiness check API along with several basic checks, plus the functionality to update core (and only core) in the UI or during cron.

    Core will also receive new third-party runtime dependencies, specifically php-tuf/composer-stager.

    The modules are being added to core in ✨ Add Alpha level Experimental Automatic Updates module Needs work .

  3. Composer support

[Not yet in scope] Phase 3 (Post-stable features)

The following features are not part of the initial core scope, but may be added in future releases once the core module is stable:

  • Automatic updates for contributed modules/themes

Initiative Team

Related initiatives

🌱 Plan
Status

Fixed

Component

Active Initiative

Created by

πŸ‡ΊπŸ‡ΈUnited States hestenet Portland, OR πŸ‡ΊπŸ‡Έ

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Production build 0.71.5 2024