Problem/Motivation
Currently Drupal core does not display any information about upcoming security releases. This means that site admins must check outside of Drupal to know whether a security release will be released soon.
Very rarely there are highly critical security releases that have the potential to affect so many sites that it would be good to notify site admins from inside Drupal.
As part of the Automatic Update initiative in #3039120: Create initial feature to display relevant PSA data in Drupal the Automatic Updates contrib module displayed PSA and SA messages from a feed from drupal.org inside Drupal itself. This feed was created in #3068539: Add psa.json API endpoint to support automatic updates and was intended also to be used by Drupal core. The documentation of this feed can be seen here:https://www.drupal.org/docs/8/update/automatic-updates#s-public-service-...
Proposed resolution
Notify site admins of PSA and SA items that appear in the json feed at https://updates.drupal.org/psa.json
This feed is used by the security team for only critical security announcements
The sites admins will be notified in 3 ways.
- On the status report page at
admin/reports/status
. - On administration pages for users who have the 'administer site configuration' permission. The message will be shown to the same users and on the same pages that the available updates messages are currently. Currently the patch offers a checkbox in the setting to turn this off. See "Remaining Questions" as to whether the checkbox should be removed.
- Via email for the emails that set to receive emails for available updates. See "Remaining Questions" as to whether there needs be checkbox to enable this. Currently the patch has a checkbox
Remaining Questions\tasks
- Do we need the setting "Show Public service announcements on administrative pages." which the contrib module has? There is not a setting for turning off the existing feature for showing available updates. Since these new messages would be much more rare do we need a setting not to show them?
Also because they are so rare 95%(percentage guessed 🤷🏼♂️) of the time if they unchecked this setting they would see no change to there site so it may not be clear why they would want to leave it on or what it actually does. If they leave it off by mistake the consequences could be very bad if they miss a critical security update.
- Do we really need a separate
psa.notify
setting to control if we send emails? Could we just send emails to the email addresses in the existingnotification.emails
setting?This setting is described in the UI now as
"Whenever your site checks for available updates and finds new releases, it can notify a list of users via email."Would sending emails now for PSAs also to these same emails be a good idea?
If we have a separate check box for "Send email notifications for Public service announcements." then you could set up to send emails for new Updates but not send for PSA's but you could not set up your site to send emails for PSA's but not Updates.
Because the PSA feed is currently being used for only highly critical items it's hard to imagine that you would want emails for Updates and not highly critical PSAs.
-
Determine if there is a way to know if the site has updated to a version covered by a PSA.
The problem with leaving PSA’s in the feed for a long time is right now there is not enough information in the feed(at least how the docs describe it) to know when to not show the PSA because the site has updated to a new secure version.
Once the version of core or contrib with a fix is published we still have to show it because there is nothing in the feed item that tells the site that a PSA is for an upcoming security release or if the release has already been made. This may a documentation issue with the description of the current feed.
If we had a property in the feed like
released
that is firstfalse
and then when the fix is out changes totrue
andinsecure
is updated with all known insecure versions after the fix then we could know when to not show it any more if the site has updated to a secure version.so the logic would be something like
if ($is_psa && (!$released || in_array($installed_version, $insecure_versions) { show_psa() }
- Determine if core should follow the same logic as the contrib module.
The contrib module currently displays all items in the feed whereis_psa === true
and the project is core or project is installed currently on the site. In addition for feed items whereis_psa === false
and the project is core or installed AND the currently installed version is ininsecure
If we only want to display highly critical PSA's then we may want to not show any feed item that is not
is_psa === true
.on #3068539: Add psa.json API endpoint to support automatic updates @drumm said
The planned use of this API is only for highly critical updates which we hope as many Drupal sites as possible set to automatically update. It does not include all PSAs.
We should get clarity if the json feed could change later to include anything other than highly critical updates. If it could then versions of core that were still in use before core changed it's logic to handle this would start to show other updates.
Currently there is nothing in the feed that specifies security risk level. We could ask for this to be added to the feed properties. Then we could filter for it now even though no other updates should be in the feed. This way if they were added later they would still be filtered out.
- Should we show PSA's for projects that are not installed? The contrib module does not but there are reasons we might want to:
- Certain remote code execution vulnerabilities might not require the module to be installed.
- A module could be installed at any point. A site admin should probably know that a critical security release is forthcoming in the next week so they can make an informed decision if they want to install a module or maybe wait until the release
- Make a list of improvements and bugs found here that should be backported to the contrib module.
- After this is released in core update the contrib module to not display PSA's if the core version install will display the PSAs. This may just meaning checking for the existence of the services added in this patch
- 🔥🔥🔥 Critical Assumes extension name and project name are the same. See #42.1
- change
getPublicServiceMessages()
to throw exceptions rather return error messages as PSA messages are returned. change the callers to react to the exception and change what is displayed for an error. - Added tests for invalid json
- Change to handle invalid versions of installed modules see #37.7(edge case)
- SecurityAnnouncement class with extra validation and getters
- Edge case: handle individual
insecure
versions that don't parse #37.6 - Throw validation error if notifications are set for PSA and no email is provided for the update module(contrib module doesn't have email setting of it's own), @see #43.2
- Don't send the same PSA email multiple times @see #43.3
enable_psa
setting in the UI is described in contrib module asShow Public service announcements on administrative pages.
but it unchecked it will also stop emails and the status report.
API changes
Interfaces \Drupal\update\Psa\NotifyInterface
and \Drupal\update\Psa\UpdatesPsaInterface
We may consider adding these interfaces later as the functionality is basically just reading a json feed and displaying info. Instead of providing an API via the interfaces we could simply check the for existence of our services in hook_cron and other places before proceeding. If a contrib module wanted to react to the PSA json in a different way it could just unset our services.
User interface changes
Critical PSA message will be displayed on the status report page and most admin pages to users who have 'administer site configuration' permission.
Status report page:
Messages on admin pages
Changing to Update settings form. Change is highlighted
Email text
SUBJECT: An urgent security announcement requires your attention for Drupal
An important security announcement is available for your Drupal site. You should
read the announcement immediately and follow its instructions.
Public service announcements:
* Critical Release - SA-2019-02-19 [1]
To see all public service announcements, visit
https://www.drupal.org/security/psa [2].
[1] https://www.drupal.org/sa-2019-02-19
[2] https://www.drupal.org/security/psa