To support the recent changes to the project application process, namely decoupling the ability to create full projects/releases from security coverage - we need to provide indicators on the update status page of which installed modules receive security coverage.
@hestenet, @drumm, and @mlhess hope to help drive this forward. @Dries has given his blessing to prioritize this patch.
We (the DA) want to get this committed as soon as possible, and so we're allocating our sprint time towards getting this ready, writing tests, and responding to any reviews.
What is the problem to solve?
Drupal projects that do not have a stable release and haven’t opted into security advisory coverage have security issues reported to their public issue queues. This leaves lots of opportunity for attackers to learn about vulnerabilities and exploit them.
There are cases where you can be relatively safe running a non-covered project, but the average site owner will not be safe in general. Site owners should be informed of the risks.
Who is this for?
Primarily site owners. They should be informed of what security risks exist so they can plan and act accordingly.
Secondarily project maintainers. They should be encouraged to opt their projects into coverage and make stable releases.
Result: what will be the outcome?
A higher proportion of Drupal sites are running a higher proportion of covered releases.
How can we know the desired result is achieved?
Update status data reported to updates.drupal.org.
The changes would need to:
- Indicate which modules have security coverage and which do not.
- Provide visual indicators of coverage status via the shield icon and the !-alert icon
- For modules that are explicitly unsupported for known security issues or other reasons, it should indicate that
In addition the changes could:
- Provide an alert on each page for admins like the 'you are using a module with a security release' warning
"How do we keep users informed about which of their modules receive security advisory coverage, in a way that educates them rather than scaring them?"
Implementation questions to be resolved:
- Where should the list of covered/uncovered modules be presented?:
[ ] a. Only on the status page
[ ] b. Only on the updates page
[ ] c. Both
[X] d. Notify on the status page, but direct users to the updates page for per-module info.
- If we put indicators on the updates page, what kind of indicators should we use?
[ ] a. Negative indicators on each module
[ ] b. Positive indicators on each module
[X] c. Both
[ ] d. A single warning at the top of the page, referring users to the list of uncovered modules on the status page.
[X] e. But separate the different indicators into separate columns
- How loud should the "Your site uses modules that do not receive security advisory coverage from the security team" message be?
[ ] a. It should follow admins everywhere, like the 'security update available message'
[ ] b. It should be at the top of the updates page, and link to the status page
[X] c. We don't need an extra message at the top.
- Should developers be able to suppress this warning, through settings.php? And if so, what should they be able to suppress?
[ ] a. The top message that follows admins around
[ ] b. The top message on the updates page
[ ] c. The warning/list of modules on the updates
[ ] d. The warning on the status page
[X] f. none of the above - We've chosen in question 3 *not* to have any message follow you around, except for the normal 'there are warnings on your status page'
[ ] g. all of the above
- Should we modify the way the colors work?
[X] a. Separate the updates rows into columns for: module name, version, up-to-date status, coverage status
[?] b. Eliminate the background colors entirely in favor of iconography
[X] c. Eliminate the background colors except for the RED warning on security updates
Before we roll this into core we may want to email maintainers to let folks know that this change is coming.
User interface changes
admin/reports/updates with added security information
The update status for available updates, including security updates and the row backgrounds, is left as-is for consistency. Security information is grouped with module support or update status.
Addition to status report
If everything is covered:
If something is not:
Turning this off
If a site builder believes they are responsible enough to run non-covered code, they can turn off these messages in
/** * Hide Drupal.org security advisory policy warnings. * * By default, Update Manager module warns about modules and themes from * Drupal.org that are not covered by Drupal.org’s security advisory policy. * * Security issues in non-covered projects are reported to the public issue * queue and will not receive coordinated security announcements. * * @see https://www.drupal.org/security-advisory-policy */ # $settings['update_warn_drupalorg_security'] = FALSE;
Theme additions in update module.
Data model changes
We have updated the update status xml to support this change:and can make additional changes as needed.
|#65||Screen Shot 2017-04-07 at 2.32.33 PM.png||197.24 KB||drumm|
|#65||Screen Shot 2017-04-07 at 2.26.08 PM.png||53.15 KB||drumm|