Enable unattended updates

Problem/Motivation

Right now, unattended updates are disabled in this module via config with no UI.

The reason for this is because we have been waiting for support for The Update Framework(TUF) to be rolled out on drupal.org's packaging pipeline and Composer facade. TUF support for Package Manager is a core requirement but requiring TUF support for cron updates in contrib does not have to be a requirement though.

When Automatic Updates gets added to Drupal core it will be used by many many more sites and sites will not be able to easily opt out of this functionality being enabled by a privileged user. For this reason once in core unattended updates provides a tempting attack if someone were to be able to comprise core itself or one of core's dependencies that would be updated during a critical security update. Once AutoUpdates is in core and a security release for Drupal is issued many sites will update without eyes on the site. This could be 10s of thousands of sites at once.

The situation is much different for this contrib module for a couple of reasons

1. This module only has 160 sites using it. Hopefully the number will increase and more rapidly if we support cron updates. But still what TUF would protect us against is supply side attacks. Updating via composer directly still has these problems
2. Any site that uses this module and eventually enables cron updates has to opt-in to this by choice, once by installing the module and once by enabling via the UI. This is very different than the code being shipped with Drupal core which is hard to opt out of

Currently many sites do not apply core security updates, even critical ones, in a timely manner.

I am not sure where to get historical but as example the 2 most recent security releases were 9.5.5 and 10.0.5 both released on March 15th

From https://www.drupal.org/project/usage/drupal as of March 18, 2023

Here are numbers for sites running secure and insecure versions:
Secure 9.5 70,489
Insecure 9.5 84,904
Secure 10.0 9511
Insecure 10.0 9,797

So in both case more sites are running insecure than secure versions of Drupal core. The usual caveats with the incomplete data about usage statistics . These are only sites with the Update module installed. But this also means 100% of these have the message that they are insecure versions of Drupal on their status report.
There are probably many reasons for this but a couple likely ones are

1. Organizations with a Drupal site may not always have a drupal developer on staff that can perform the updates
2. Even organizations with staff that can perform updates may be limited by developer time(money) especially if they have many sites. Those sites could be within 1 organization or a development agency that hosts many drupal sites

Because of the above sites choosing to install this module and enable cron updates will be solving an existing security issue, not being able to apply security updates in a timely manner. If this module already had TUF support we could offer an even better solution but  depending on a site’s needs the current module’s functionality may still be a security improvement.

Security Enhancements

Although this module does not currently have TUF support it does have a few other security features over using Composer directly

1. Package Manager does not work if Composer’s default setting for  secure-http is overridden. This means Composer will always fetch it’s metadata and package files via https.
2. Drupal’s default settings for update_fetch_with_http_fallback cannot be overridden. This means that requests for Update XML which the site will use to determine if there is an update to be applied will always be fetched with https

Current module status

8.x-2.0 first stable release of the Composer compatible version of this module was released on July 21, 2022.  We have not had any security problems reported with this module since then. The CronUpdater class is pretty small and cron updates mostly use the same logic as form updates. Cron updates are even more restrictive though in that they will not allow updates if there will need to be database update and are limited to patch updates.

The cron updater will email the site owner if there is an update available but it cannot be applied and if an update has been successfully applied.

Proposed resolution

Fix all the remaining tasks, then add a UI for enabling unattended updates.

Unattended updates should be disabled by default but a message should be displayed when the user enables the module.

Here is the commit where remove the form alter that added the cron updates to the Update setting form https://git.drupalcode.org/project/automatic_updates/-/commit/a001dacffe...

It could be used as a starting point. We already have tests for cron update but we could update test coverage that form enables and disables cron updates

Remaining tasks

Must have's

1. #3281340: [Plan] Send emails
2. #3299612: Send an email when an unattended update fails
3. #3285491: Send an email when a cron update succeeds
4. #3293422: Don't allow cron updates if Xdebug is enabled
5. #3293146: Don't run cron updates with PHP's built-in web server without an alternate port
6. #3351895: Add Drush command to allow running cron updates via console and by a separate user, for defense-in-depth
7. #3359727: Add new setting for how unattended updates will be run
8. #3360763: Switch failure marker file from *.json to *.yml to prevent it from being readable from the web

Needed before alpha release with unattended updates but can be done after this issue is committed.

1. #3360656: For web cron updates run each stage life cycle phase in a different request
2. #3362695: Create documentation for using the auto-update terminal command

Follow-up issues for core inclusion

1. #3316617: Add a validator to check that PHP-TUF's Composer integration is present and configured correctly