Problem/Motivation

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.

Proposed resolution

The changes would need to:

  1. Indicate which modules have security coverage and which do not.
  2. Provide visual indicators of coverage status via the shield icon and the !-alert icon
  3. 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

Key Question:

"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:

  1. 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.
  2. 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
  3. 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.
  4. 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
  5. 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

Remaining tasks

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

Screenshot
The update status for available updates, such as security updates, is left as-is for consistency.

Addition to status report

If everything is covered:
Screenshot

If something is not:
Screenshot

Turning this off

If a site builder believes they are responsible enough to run non-covered code, they can turn off these messages in settings.php:

/**
 * 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;

API changes

Theme additions in update module.

Data model changes

We have updated the update status xml to support this change: #2853696: Add security advisory coverage to update status XML and can make additional changes as needed.

CommentFileSizeAuthor
#116 2766491.patch26.53 KBdrumm
#115 2766491.patch26.53 KBdrumm
#110 2766491.patch26.46 KBdrumm
#108 2766491.patch26.32 KBdrumm
#108 Screen Shot 2017-06-20 at 5.43.07 PM.png158.21 KBdrumm
#107 Screen Shot 2017-06-20 at 5.31.47 PM.png148.2 KBdrumm
#104 2766491.patch25.8 KBdrumm
#102 covered-not-covered-grouping.png15.31 KByoroy
#101 security coverage 3.png148.2 KByoroy
#100 security coverage 3.png147.96 KByoroy
#98 2766491.patch25.34 KBdrumm
#95 warnings-statuspage.jpg362.64 KBjaperry
#93 after-patch.png85.44 KBDavid_Rothstein
#93 before-patch.png75.61 KBDavid_Rothstein
#92 after-patch.png85.63 KBDavid_Rothstein
#92 before-patch.png77.2 KBDavid_Rothstein
#87 2766491.patch23.07 KBdrumm
#87 Screen Shot 2017-05-18 at 3.59.23 PM.png144.5 KBdrumm
#87 Screen Shot 2017-05-18 at 3.59.38 PM.png22.93 KBdrumm
#84 security coverage wireframe.png87.64 KByoroy
#83 security coverage 1.png89.1 KByoroy
#82 update-status-security-info-design.png18.82 KBDavid_Rothstein
#65 Screen Shot 2017-04-07 at 2.32.33 PM.png197.24 KBdrumm
#65 Screen Shot 2017-04-07 at 2.26.08 PM.png53.15 KBdrumm
#65 2766491.patch19.04 KBdrumm
#62 2766491.patch17.52 KBdrumm
#62 Screen Shot 2017-04-05 at 5.22.26 PM.png44.17 KBdrumm
#60 status-report-experimental-modules.png187.95 KBDyanneNova
#56 update-status-hestenet-info-shield-grey-crop.png57.99 KBhestenet
#55 update-status-1.3.0.jpg136.4 KBDyanneNova
#49 uptodate-grey.png2.21 KBifrik
#49 security-advice.png2.51 KBifrik
#44 2766491.patch17.07 KBdrumm
#41 2766491.patch17 KBdrumm
#39 2766491.patch17 KBdrumm
#33 2766491.patch12.83 KBdrumm
#30 2766491.patch11.56 KBdrumm
#27 2766491.patch11.48 KBdrumm
#27 Screen Shot 2017-03-20 at 5.48.07 PM.png18.63 KBdrumm
#27 Screen Shot 2017-03-20 at 5.47.21 PM.png21.36 KBdrumm
#25 Screen Shot 2017-03-18 at 10.35.22 AM.png85.41 KBdrumm
#25 Screen Shot 2017-03-18 at 10.34.51 AM.png242.87 KBdrumm
#25 2766491.diff9.08 KBdrumm
#20 2766491.diff8.65 KBdrumm
#18 Screen Shot 2017-02-27 at 5.37.07 PM.png86.12 KBdrumm
#18 2766491.patch8.58 KBdrumm
#15 2766491-security-coverage-17.patch9.42 KBpwolanin
#11 Screen Shot 2016-08-12 at 8.37.31 PM.png43.76 KBcilefen
#11 update_status_should-2766491-11.patch7.55 KBcilefen
#11 interdiff.txt7.74 KBcilefen
#10 update_status_should-2766491-10.patch1.28 KBcilefen
Membership dollars fund testing for the Drupal project. Drupal Association Learn more

Comments

hestenet created an issue. See original summary.

David_Rothstein’s picture

Issue tags: +needs backport to D7

For modules that do not have security coverage, highlight them in yellow.

I'm pretty sure yellow is already used for other things (for example, a module that has an update available, but the update isn't security-related). Also, even for a module that doesn't have security coverage, there should still be a way to indicate all the various states that are currently indicated via color: module is up-to-date, module is not up-to-date, module is not up-to-date and a security update is available, etc. So this needs some more thought.

Probably this should try to use something as similar as possible to whatever design comes out of #786702: Add information about releases covered by security advisories to project pages near download table (in order to promote consistency between what people see on drupal.org compared to what they see on their own sites)?

hestenet’s picture

Probably this should try to use something as similar as possible to whatever design comes out of #786702: Add information about releases covered by security advisories to project pages near download table (in order to promote consistency between what people see on drupal.org compared to what they see on their own sites)?

That's a good idea.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

mforbes’s picture

With the new shield icon now deployed on production d.o, I naturally expected to find this thread on adding it to update.module's admin/reports/updates (to use D7 parlance, as I'm not a D8 user yet).

Having the shield on project pages informs about whether or not to install a project; having it at admin/reports/updates would inform about whether or not to keep a project installed. For someone looking to have only covered projects installed, indicators in both of these places would be more comprehensive than just the former alone.

cilefen’s picture

So that is a +1?

cilefen’s picture

I am asking around to find out if this isn't soft-postponed on a theoretical issue to update the XML.

drumm’s picture

Yes, the XML needs to have the data before core can show it.

I do recommend getting a head start on implementation here if possible.

The <release> elements will get a new child with a straightforward value. Maybe <security>covered</security>/<security>not covered</security>

mforbes’s picture

So that is a +1?

Yup.

<security>covered</security>

Something that simple surely makes sense, but is the word "covered" (or variations thereof) already being used in machine-readable places such as d.o's field names and views config? If not, meaning it's merely part of (translatable) strings like the shield's alt text and legend, then we might be wise to avoid it given this explanation of what the indicator really means. It's also worth considering whether or not this will be binary forever. In any case, it should be informed by any machine names that have already been put into use anywhere else.

cilefen’s picture

Status: Active » Needs work
FileSize
1.28 KB

This is as far as I got but I'm quitting for the day.

cilefen’s picture

Wherever we go with styling this, it is to be determined if we simply let the value pass through to the theme layer like this, or update the update status (even adding a new status constant) as it is passed around.

drumm’s picture

Actually, a bit of text for the message would be good to include in the XML. Links would be good to be able to use; the text should be otherwise well-sanitized so hacking Drupal.org isn't (more of) a risk to individual sites.

With the D6 end of life, we ran into limitations on what we could communicate via update status, which was not a fun to figure out. See #2687957: Improve Update Status messaging for End of Life in Drupal 7(and Drupal 8 and later).

miwayha’s picture

@drumm: Consider this status message or modules and themes not covered by the Security Team's disclosure policy:

Caution: Your site uses contributed modules and / or themes that are not subject to the Drupal Security Team's Responsible Disclosure policy. Production sites should exercise care in using such modules and / or themes. For more information see https://www.drupal.org/security-team.

mj-19’s picture

Issue tags: +MWDS2016

Building upon what @miwayha wrote:

Caution: Your site is at risk. Your site uses modules and / or themes that are not subject to the Drupal Security Team's Responsible Disclosure policy. Use of such modules and / or themes may expose your site to security vulnerabilities. For more information see https://www.drupal.org/security-team.

pwolanin’s picture

Starting on a test fixture change

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

drumm’s picture

#2853696: Add security advisory coverage to update status XML added the data to updates.drupal.org. All XML generated after now will have the new elements. In addition to regenerating after commits on a dev release and making a new release, the whole thing is regenerated daily too. So everything should have the new elements tomorrow.

If the new element contains text, that’s the reason something isn’t covered and should show up in the UI. <security covered="1"/> means things are good. For example:

https://updates.drupal.org/release-history/bad_judgement/7.x
has <security>Project has not opted into security advisory coverage!</security> on every release.

https://updates.drupal.org/release-history/api/7.x
has <security>Beta releases are not covered by Drupal security advisories.</security> on beta releases.
and <security covered="1"/> on full releases.

This helps us with #2687957: Improve Update Status messaging for End of Life in Drupal 7(and Drupal 8 and later) by letting arbitrary plain text in:
https://updates.drupal.org/release-history/api/6.x
<security>Drupal 6 and earlier are not covered by Drupal security advisories!</security>

drumm’s picture

Status: Needs work » Needs review
FileSize
8.58 KB
86.12 KB

The attached patch builds on #15:

  • Updated test fixture XML to match what is now in production on updates.drupal.org
  • Flattened the shield even more to keep up with Drupal.org project pages.
  • Added reason for not being covered from update XML.

Screenshot

This only shows the information for versions you might want to update to. I think the goal, wearing my security team hat, is to have some indication on the projects you have installed. We could do any of:

  • Show the shield on covered projects you have installed.
  • Show the reason for not being covered on projects you have installed.
  • Put a warning or error at …/admin/reports/status when you have not covered projects installed.
hestenet’s picture

@mlhess, and @drumm, and myself had a call and reviewed this:

- We like the copy from comment #14 for the non-covered releases.
- We'd like to move the shield icon to the left side of the release information to make it more visible.
- We'd like to add the [covered shield] and the [!shield icon for non-covered releases] in the already installed modules list.
- We could use some design work in terms of how to layout these icons and messages in a sensible way - help welcome

drumm’s picture

Status: Needs review » Needs work
FileSize
8.65 KB

(Simple-reroll of #18 for array code style, and being able to apply to 8.4.x today.)

alexpott’s picture

@mlhess asked me to look at this from a framework manager perspective. There's not much architecture here - I like re-using the shield from d.o - that makes lots of sense. And it'll be good to contrast the security covered modules with those that are not. I definitely think it is worth adding a warning when using modules from d.o not covered by the security policy and #14 looks good in terms of copy. Obviously custom code needs to be excluded. It'd be great to add tests given the importance of putting the shileds on the right modules.

hestenet’s picture

One additional element that would be good here is to include the 'You have projects that are not subject to the drupal security advisory policy' message in same kind of warning message like the 'you have modules with security releases' message - that follows admins around the site.

It should be something that can be disabled in something like a settings.local perhaps though.

mforbes’s picture

+1 to #22 given the overall trend that admins should be made aware of a lack of coverage to the same extent that they are made aware of available security updates.

I'm on the fence about that option to suppress the messages though. I suppose that option would suppress both the existing message (updates available) and the new message (not covered). I feel this could lead to an unscrupulous developer, who is at the tail end of a fixed-price contract and had one of these messages just pop up before delivery with no maintenance contract, enabling this option before the client could notice and ask what gives. Then there's an insecure site in the wild, maybe the client has some internal turnover and there's a new custodian who is then also oblivious to this option instead of figuring out that they should get maintenance, etc. etc.

Anyone using such a thing non-maliciously could just as well ignore the messages, instead.

David_Rothstein’s picture

I would suggest that a message which appears on all admin pages should be discussed in a separate issue. (That's a pretty big user interface change compared to what was originally proposed here - which is limited to the Update Status report only.)

drumm’s picture

Status: Needs work » Needs review
FileSize
9.08 KB
242.87 KB
85.41 KB

This patch:

  • Adds the warning message if you are running uncovered modules from Drupal.org. That won’t show for custom modules not available from Drupal.org.
  • Adds help text explaining the security shield.
  • Moves the shield, or explanation for why something is not covered, from suggested upgrades to what you are currently running. I think we we showed it in both places the page could get quite busy.

Screenshot
Screenshot

To do:
Tests
Design - I grouped security coverage with up to date status
Copyediting - is everything clearly worded and warnings of appropriate severity?
When uncovered projects are running, add the warning to admin/reports/status

Status: Needs review » Needs work

The last submitted patch, 25: 2766491.diff, failed testing.

drumm’s picture

Status: Needs work » Needs review
FileSize
21.36 KB
18.63 KB
11.48 KB

This patch should fix the notices in the last test run and adds either of the following messages to …/admin/reports/status

Screenshot

Screenshot

Personally, I’m not sure we want to put a message on every page. This is important for admins to know, but I’d say it is an order of magnitude less important than running known insecure code, which is the only case we message on every page for admins, that I know of. Conceptually, it is about the same risk, but having an SA with an upgrade to do is a lot more actionable than a project with real potential to have public reports.

hestenet’s picture

Issue summary: View changes
Issue tags: +Needs backport to 8.3.x

Status: Needs review » Needs work

The last submitted patch, 27: 2766491.patch, failed testing.

drumm’s picture

Status: Needs work » Needs review
FileSize
11.56 KB

Fixing notices only. Not all the test fixtures have the new XML elements, it is good to test for that case.

Status: Needs review » Needs work

The last submitted patch, 30: 2766491.patch, failed testing.

hestenet’s picture

Copy suggestions:

Re: #25

The warning message copy at the top seems good to me.

I think the language next to each module/version is concise and informative.

  • Moves the shield, or explanation for why something is not covered, from suggested upgrades to what you are currently running. I think we we showed it in both places the page could get quite busy.

This is a bit tricky, if I'm looking at a module I already have installed, which is one which does *not* have security advisory coverage on the particular release I'm using - I would find it very reassuring to know whether or not the release being recommend to me does. (As in #18). I don't necessarily need that signal for the 'latest version' and the 'development version' just the 'recommended release' - I think.

Re: #27

I think we might want to adjust the language slightly:

Drupal.org Security Advisory coverage All modules and themes from Drupal.org that are currently installed receive coverage. Learn more about security advisory coverage.

I think the 'Not all modules....' message can probably stay as it is.

drumm’s picture

FileSize
12.83 KB

I shortened up the last suggestion:

Currently installed modules and themes from Drupal.org receive coverage.

This patch also starts adding testing.

drumm’s picture

Status: Needs work » Needs review

The last submitted patch, 10: update_status_should-2766491-10.patch, failed testing.

The last submitted patch, 11: update_status_should-2766491-11.patch, failed testing.

The last submitted patch, 15: 2766491-security-coverage-17.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 33: 2766491.patch, failed testing.

drumm’s picture

Status: Needs work » Needs review
FileSize
17 KB

I found the bit of changed markup causing the failed test, and added a test for the shield appearing when a project is covered.

Status: Needs review » Needs work

The last submitted patch, 39: 2766491.patch, failed testing.

drumm’s picture

Status: Needs work » Needs review
FileSize
17 KB

Fixing my failing test.

Status: Needs review » Needs work

The last submitted patch, 41: 2766491.patch, failed testing.

hestenet’s picture

Adding tags just to suggest that a designer's eye would be welcome. I think it looks pretty okay - but I'm sure it could be improved.

drumm’s picture

I got the tag added in ccc_update_test.1_0.xml in the wrong place in the last patch.

xjm’s picture

I don't think "Needs design review" is actually a thing that anyone looks at, but I think what we actually care about is the usability impact of the design, so tagging for those topic maintainers.

It would be best to put current screenshots in the summary, but #25 and #27 are probably accurate.

xjm’s picture

FWIW, to me, the black shield icon looks like a bad thing rather than a good one, like it might be a different kind of bad warning like the yellow triangle. But I am not a usability professional.

drumm’s picture

Issue summary: View changes

It would be best to put current screenshots in the summary, but #25 and #27 are probably accurate.

Done, with the issue summary template. And yes, those are current screenshots.

drumm’s picture

FWIW, to me, the black shield icon looks like a bad thing rather than a good one, like it might be a different kind of bad warning like the yellow triangle. But I am not a usability professional.

I’m happy to change it as needed. I also think some brief explanation to go with the added help text would be good.

On Drupal.org, we use CSS like filter: opacity(0.5) drop-shadow(0 0 0 #fbf03b) brightness(2); to change the color of the icon to match the background. I don’t see filter: used outside of 3rd-party things in core; I’m not sure if it is an appropriate level of cleverness for core.

ifrik’s picture

FileSize
2.51 KB
2.21 KB

About #46

FWIW, to me, the black shield icon looks like a bad thing rather than a good one, like it might be a different kind of bad warning like the yellow triangle. But I am not a usability professional.

On drupal.org, this shield is grey rather than black when it's part of an explanation. So maybe just changing it to the same grey, would make it look less like a "bad thing" and consistent with d.o.

Bojhan’s picture

A few questions:

  1. Can we just show the shield for when something is wrong? Not for when something is right (e.g. you got security team coverage). We should not be littering icons all over this page - that will make the ones you do have to pay attention to, not stand out.
  2. The explanation is a little long and verbose. What about "Not security checked".
  3. We shouldn't explain the icon in the text above, if the icon + text needs explanation. There is likely something wrong with the icon and text.
  4. From a design point of view, we likely need the shield to have some actual color + maybe a stripe down the middle. The current styling is not in line with other icons,
    I would typically use the same color as we use elsewhere (e.g. orange for warning = not covered, red for error = actual security fault) to denote importance.
drumm’s picture

Can we just show the shield for when something is wrong?

Drupal.org project pages have the shield as a positive thing, I wouldn’t want to reverse this within Drupal installs.

The explanation is a little long and verbose. What about "Not security checked".

The security team doesn’t really do anything that’s broadly “checking”. We encourage potential vulnerabilities to be reported to us, triage them, and work with maintainers to get a release and security announcement.

mlhess’s picture

Correct, the security team does not proactively check anything (as a core function, some team members do)

We already have both positive and negative alerts on this page. I think it would be great to change the page so we only alert to what is wrong, but that is scope creep on this issue.

mlhess’s picture

Drumm is correct as well, we should match the messaging on D.O.

drumm’s picture

We already have both positive and negative alerts on this page. I think it would be great to change the page so we only alert to what is wrong, but that is scope creep on this issue.

For security coverage, that actually cuts down the issue by half and solves most of Bojhan’s concerns.

We wouldn’t add the shield, so we don’t need to explain it. On the update status details, we’re only adding the specific alert if something isn’t covered.

DyanneNova’s picture

FileSize
136.4 KB

I think it's helpful to have positive notices on the update page. It reassures site administrators that everything is in correct order on their site.

We could take a positive approach to this and use icons to inform administrators of what modules do have security coverage, while educating them in the text as to what a lack of coverage means for them.

I think we can use a shield with a checkmark to convey both "covered and currently believed to be secure" and a shield with an exclamation point to indicate "covered and has a known security vulnerability".

In that case, anything without a shield would indicate that there is no security coverage on the module. Text in bold explains what that means for the uncovered modules.

Here's an example mockup:

mockup of update page security coverage

hestenet’s picture

Re: #55

Visually, I think this is a much cleaner implementation. Though I think it goes in the opposite direction of comment #54: showing only positive indicators vs. showing only negative indicators.

So while I like this visually, I'm very much concerned about signaling lack of coverage only through the absence of an indicator (or, I suppose, the bolded text in the example screenshot posted above.) I fear that a user could easily skim past the explanation at the top.

At the same time, I can see how giving the lack of coverage indicator the same visual weight as 'Security update required' could backfire. If a user chooses to ignore the 'lack of coverage' indicator they might unwittingly begin to ignore the 'update required' indicators as well.

Here's one attempt at a middle ground:

update status indicator for 'not covered'

Bojhan’s picture

@mlhess @drumm I am happy to change the messaging on D.O if that needs to match whats here.

Lets take the first step and only warn, when something is wrong. I understand that it feels reassuring, to add it everywhere - but really unsure about the clutter it adds as people won't notice it as much if we have icons scattered everywhere. Honestly even the "up to date" message we have on everything is a lot, but a bit much to change now.

I am not sure about the direction this issue is taking.

japerry’s picture

Status: Needs review » Needs work

Others can correct me if I'm off base here: But it is pretty important that the status page shows us three things for modules/themes:

  • up-to date
  • has a new version available
  • has a security update available

I don't really need or want anything else. When we're building sites, most people are making a conscious decision to use a module version and don't really think/care about security coverage. Having a note at the top showing that some modules have additional security coverage is great, but I certainly don't want to see warnings on my site if one of the module versions I use isn't the recommended release. I'm more concerned about active security issues, and not about boogie man theoretical vulnerabilities because a module isn't being watched by the security team.

In fact, I'd go so far to say, if the change was made to comment #54, I'll make a module to disable that functionality. Its a super bad user experience, and gives clients the impression their site is not secure, when that is not the case. I don't think a single Drupal 8 site can use only recommended modules right now, so it'd give the impression that Drupal 8 is not secure.

EclipseGc’s picture

So, I'll admit, I glossed over this issue, and I know we'll do whatever we're going to do regardless of my opinions however...

Trying to communicate all of this information in a single list seems confusing to me. As a long time member of the community, I understand much of this data already, but if we want someone to visit this page of their site and intuit what's going on, a single list of data is going to be difficult to comprehend. Can I suggest that we might consider leaving the existing list largely alone and adding a new list that communicates exactly which installed modules are not covered by the security team? That would, imo, communicate much more clearly and concisely about the two different sets of problems we're trying to tackle without conflating them together.

Just a suggestion. Carry on.

Eclipse

DyanneNova’s picture

After looking at this more, I noticed that we already have a pattern for this kind of information in core with experimental modules.

Instead of adding extra information to the Updates page, why don't we list all of the modules that lack security coverage under a warning on the Status report page?

That gives the user a clear alert as to the potential problems, lists all of the modules with that issue, and follows a current ux pattern we have.

status report showing experimental modules enabled

drumm’s picture

See “Addition to status report” in the issue summary, and #27. Currently, it is linking over to the update status page. We could have it list the non-covered modules out right on the update status page.

The ability to configure away these warnings has been tossed around.

drumm’s picture

Issue summary: View changes
Status: Needs work » Needs review
FileSize
44.17 KB
17.52 KB

This patch adds the specific modules not covered to the status report page:

Screenshot

The text for each module is from updates.drupal.org and can be revised at any time as we change/clarify policies, or learn how to copyedit.

I’ve left in all the work on the update status page for now. We need to decide:

  • Is the status report alone sufficient?
  • Or should we ditch the shields and only show negative information when necessary on the update status page?
  • Do we need to keep everything?

I’ll continue work on this to add tests as we get clarification. And a settings.php configuration to ignore the warnings.

DyanneNova’s picture

I think we can remove the explanations for the lack of coverage on the warning and instead explain on the security advisory coverage document that Dev and RC releases aren't covered. That cuts down on redundant messages for the same information. I'm not sure that users need the release information. If they choose to update to a release with security coverage they'll likely need to do much more research to understand what their options are.

That would make this look a bit closer to the Experimental Modules warning, like this:

Modules or themes without security advisory coverage found: Drupal core, Devel, Token. Learn more about Drupal.org security advisory coverage.

I think that's enough without changes to the updates page. It gives the site admin a warning when they check their status. It tells them what modules or themes are at potential risk, and gives them a link to more information about that risk and what they can do to improve the situation.

hestenet’s picture

Issue summary: View changes

Updating the issue summary to more clearly state the implementation questions that have been asked and still need to be resolved.

As we continue to work here in the issue, I have also reached out to the @yoroy on the Usability team to see if the DA and members of the Security Team could join one of the upcoming Usability meetings to hash out answers to these questions (or set up an independent call if needed.)

drumm’s picture

Issue summary: View changes
FileSize
19.04 KB
53.15 KB
197.24 KB

This patch adds the killswitch to settings.php:

/**
 * 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;

I’m also updating the issue summary with an additional example installed, to show another way a release might not be covered.

Screenshot

Layout plugin currently hasn’t opted into the security advisory policy. (This is somewhat equivalent to running a sandbox project for security coverage.) The maintainers can make a 8.x-1.0 release without any change in coverage.

I agree the messages are repetitive, we can change them, but I do want to offer some explanation of why exactly a specific project isn’t covered without sending people to figure it out for themselves.

David_Rothstein’s picture

Normally when there is a warning in the Status Report, we also provide instructions to site administrators on how to fix the problem.

What would the instructions say in this case? All I can think of is "uninstall the modules", but that seems like a very disproportionate and unrealistic solution for most sites...

For that reason, I'm not sure that a warning message in the Status Report actually makes sense here.

David_Rothstein’s picture

I think the actual message we're trying to get across to site administrators is something like this:

"The system is not able to tell you whether these modules have known security issues or not"

That manifests itself in two ways:

  1. There might be a public issue on drupal.org discussing a known security vulnerability, so it's your job as a site owner to either keep an eye out for those or otherwise just live with the risk.
  2. If a newer release of the module is available, there is a chance it might contain security fixes, even if it isn't labeled as a security release in Update Status. So you have to either assume it might contain a security fix, or read/understand the release notes to find out. (Note: This is also why I think it makes sense to have this info on the Update Status page after all, since that is the page you go to in order to see what new releases are available.)

I'm not sure how to express the above via a graphical icon... but something like a shield with a question mark inside it comes to mind?

yoroy’s picture

Although this is not necessarily an optional idea I think it would still be helpful to get answers to the 4 questions we ask when reviewing core ideas:

What is the problem to solve?

(Missing functionality X, prevent Y from happening, make Z easier to do)

Who is this for?

(Evaluators, site visitors, content authors, site managers, (advanced) site builders, frontend developers, backend developers, core developers, site owners, other?)

Result: what will be the outcome?

(Describe the result: how will this improve things for the stated audience(s)?)

How can we know the desired result is achieved?

(Usability test, a metric to track, feedback)

I'm especially interested in 3 and 4: what positive change are we aiming to achieve and what could we track to measure if that's what's happening?

drumm’s picture

Issue summary: View changes

Good questions - I added answers to them to the issue summary.

hestenet’s picture

Issue summary: View changes
hestenet’s picture

Issue summary: View changes
hestenet’s picture

Issue summary: View changes
hestenet’s picture

Issue summary: View changes
hestenet’s picture

Today (April 18th at 12pm PST) we had a call with the UX team, DA Staff, and members of the Security Working Group to help sort out some final implementation questions for this issue.

We made the following decisions:

  • There should be a warning on the status page about modules without security coverage, which links to the updates page for specific information as to which modules. This is the same pattern already in use for other status messages which direct users from the message to the appropriate page for action.
  • The updates status information should be refactored into columns instead of the current conglomeration of rows. There should be columns for:
    • Module name
    • Version
    • Includes
    • (these first three could perhaps be a single column?)

    • Up-to-date status
    • Security coverage status
  • Background colors on update status rows are confusing, because there are multiple kinds of status information being conveyed (hence the suggested columns above) - background colors should either be restricted to their individual columns, or eliminated in favor of iconography. With the possible exception of 'security update required' retaining the bright red warning.
  • Security coverage status should be somewhere between 'update required' and 'everythings green' in terms of loudness/scariness. We don't want to scare users with an unactionable problem, but we want them informed.
  • Security coverage status does not need a huge wall of text, though it would be valuable to have updates.xml based text available for future changes to security policy or in the next end-of-life cycle. We should link the icons to explanations of what they mean in some way (perhaps simply linking back to the status message text).
  • There does not need to be any special messaging that follows users around. The normal 'there are issues with your site' message that directs users to the status page from the configuration admin page will suffice
    • Therefore, we do not need a toggle to disable the messaging.

We need design work to figure out what the columns/background colors/iconography should look like, and we should do a comparison of the accepted design to Drupal.org's own security signals and pull in those changes to D.O as well for consistency where appropriate.

yoroy’s picture

phenaproxima’s picture

I have a question here, although it may be out of scope -- our minimum version of PHP for Drupal 8 is still 5.5.9. Which is way beyond its end of life, and no longer receiving any security fixes. And yet, our status page does not warn about that at all. Why not?

IMHO, the current generation of the patch (as seen in #65) is too strong. I don't think this should be a warning. I don't even think it should include exclamation points. It should be a notice -- a thing to be aware of, if you care to know. We should be critically careful not to scare the hell out of the people who will be using non-covered modules (which might include custom modules and forks), which I'm guessing will be the overwhelming majority of even mildly complicated Drupal sites.

ohthehugemanatee’s picture

This is very important, especially to encouraging security coverage status in contrib modules.

The devil is in the details - just how scary and intrusive the warnings are. Too intrusive, and site maintainers will ignore the really critical stuff, because "those messages are always there." Not intrusive enough, and we won't pressure maintainers into SA coverage. In the worst case, we'll have module maintainers marking unstable code as 1.0, just to silence the warnings for their users.

Part of the problem is that we don't have any kind of intermediate error status available. Just errors (fatal), warning (action item that must be resolved), and informational. Almost every site will have to ignore this warning, if they use:

* custom sandbox modules
* a dev/alpha/beta module

Has anyone on this thread EVER built a site without any of these?

It's also a laughable comparison to the things that we DON'T warn about:

* patches, even core patches, even core patches that aren't sourced from d.o issues
* known insecure PHP versions
* known insecure library versions

There is an important difference between "this isn't subject to a responsible security disclosure process" and "this has a known security issue". One of these messages will occur on a majority of Drupal sites, and people can choose to ignore it dependent on their context. The other one of these messages is a serious warning that should block a site launch. If we don't differentiate, we are stuck either over-emphasizing one message, or under-emphasizing the other.

japerry’s picture

Status: Needs review » Needs work
Issue tags: +Needs usability testing

There should be a warning on the status page about modules without security coverage, which links to the updates page for specific information as to which modules. This is the same pattern already in use for other status messages which direct users from the message to the appropriate page for action.

First, lets identify what a 'warning' is on the status page. These are (or should be) actionable items that a site builder can take to eliminate said warning on their site. But this warning (as well as experimental modules) has no immediately actionable item, except tearing their website down to only full releases, covered by the security team. While it'd be great to think we could use these warnings to push for stable releases, the simple fact is, it won't. This issue reeks of politics (throwing a 'bone' to the security team for the project application process) and not a solid UX or technical implementation.

However, I agree that somewhere on the status page, as a notice, would be a good place to mention if the site contains modules that aren't part of security coverage. This could be a link to a page on the site listing the modules, or a page on drupal.org that goes into the nuance about security coverage.

Security coverage status should be somewhere between 'update required' and 'everythings green' in terms of loudness/scariness. We don't want to scare users with an unactionable problem, but we want them informed.

No, security coverage should not be mentioned here at all. The update status page is to be about updates and known security updates, nothing else. Security coverage doesn't fall under this, pollutes the update page, and unnecessarily will scare users.

Its also important to know that the decision to choose a module is where this messaging should be, not a constant nagging. I support (for the most part) the current messaging on drupal.org, and would suggest making a way to warn builders before enabling a module not covered by the security team.

two more issues that should be addressed before this issue moves forward

  • The UX team should own this issue, not the security team. They should be a stakeholder, not the ones pushing this forward. Other users should also be involved in this decision, as it has wide implications for agencies, site builders, and customers.
  • This issue should have usability testing of different scenarios on the update page and status page.

This issue is extremely important to get right. If it is done wrong, the community will make a contrib module to revert this change.

hestenet’s picture

I absolutely agree that good UX design is critical to this issue. That is why we had a meeting about this with as many stakeholders as we could pull together on April 18th, hosted by the UX team.

#74 summarizes the minutes from that meeting with the UX team. And #75 has the recording if you'd like to view that.

I hear the fundamental concern very clearly: Don't scare users away from using Drupal. That was very much a topic of conversation during that call, and nobody wants that.

The decision-tree/check-boxes outlined in the "Implementation questions..." section of the issue was filled out collaboratively during that call.

However - please note that the current mocks and current patch do not represent the outcome of that call. We haven't had a chance to roll a new patch, and we were hoping for a new round of design mocks to work from. (I believe @dyannenova was going to work on new mocks if she has the time to do so- maybe we can sync up during Baltimore sprints?)

To address a few of the recent comments:

#76

  • Re: Warning about the security of non-Drupal software (end-of-life php versions)
    • Definitely out of scope. :) That said, I think it's perfect reasonable to provide security and security coverage related messaging about Drupal software/extensions within Drupal
  • Re: Custom and forked modules
    • Correct, this messaging should not apply to custom modules. And even the current(outdated) patch does not add messaging to custom modules.

#77

  • Re: the 'scariness' of the messaging / warning vs. informational
    • As said above - agreed, this should be informative, not frightening. This will require design
    • Yes, informational messages should be differentiated from actionable warnings like a security release.

#78

  • Re: incentivizing stable releases/opt-in to coverage.
    • We actually have already seen several examples of projects making stable releases motivated by the the project page messaging, which I think shows that this can be a successful incentive.
    • Whether it will or won't be is more something to *measure* rather than speculate on, in my opinion, and I think it's not the primary motivation of the issue, though it is a secondary one
  • Re: whether this info should be on the status page vs. the updates page
    • During the call with the UX team, we definitely suggested that a message at the top of the updates page referring users to the status page to get the list of modules was one option. It was actually, if I remember correctly, @ckrina, who redesigned the status page for D8, who suggested that we should do the opposite, and put the message on the status page referring users to the updates page.
    • That was why we eliminated having any kind of message that would 'follow users around the site' for this, because that would simply become another factor for the the status page's normal 'There are issues with your site' message that appears on the admin/configuration page.
  • Re: ownership of this issue
    • As with any core issue, we'll need to get to an RTBC. I think we have a good selection of the stakeholders active in this issue, and we had many of them on that last call.
  • Re: usability review/testing
    • It would be great to have usability review/testing of the next round of design/patch on this issue

I think the last call on this issue with the UX team was very productive, and I'd encourage folks to check out the recording for some of this discussion.

I'm hopeful that the next set of design mocks can strike accomplish the goal of being informative without being frightening.

fuzzy76’s picture

I actually think that the warnings _should_ be scary. Running alpha/beta in production is a dangerous thing. The real change that would / will fix this is that maintainers need to actually push stable releases more often and stop leaving their modules in beta for five years. And if they get more complaints from users because of this, it might actually happen.

David_Rothstein’s picture

  1. There should be a warning on the status page about modules without security coverage, which links to the updates page for specific information as to which modules. This is the same pattern already in use for other status messages which direct users from the message to the appropriate page for action.

    But again, what is the "action" in this case?

    There is nothing they can do from the updates page to make the warning go away -- and nothing realistic that they can do at all to make it go away. See my comment in #66, and @japerry makes a similiar point in #78.

  2. The updates status information should be refactored into columns instead of the current conglomeration of rows. There should be columns for:
    ....

    • Up-to-date status
    • Security coverage status

    ...
    background colors should either be restricted to their individual columns, or eliminated in favor of iconography.

    These are big changes that seem out of scope for this issue, and (more important) I'm worried they would put way too much focus on the security coverage status information. The security coverage indicator should not be as prominent as the up-to-date indicator, but this design change would tend to make them equally or almost equally important.

    Also, these changes seem like they would directly contradict Bojhan's concerns from #50:

    Can we just show the shield for when something is wrong? Not for when something is right (e.g. you got security team coverage). We should not be littering icons all over this page - that will make the ones you do have to pay attention to, not stand out.

    I think that putting this info on the update status page does make sense (I disagree with @japerry on this, for the reasons I mentioned in #67) but it should be a simpler change that just adds a small bit of information to the existing design.

  3. There does not need to be any special messaging that follows users around. The normal 'there are issues with your site' message that directs users to the status page from the configuration admin page will suffice

    I agree with the conclusion, but don't understand the reasoning :) The "there are issues with this site" message only appears in the admin interface if there are errors with your site, not warnings (which is what you are proposing to add).

David_Rothstein’s picture

I really suggest considering a simpler design, such as the one @hestenet posted in #56 (bottom panel only). I'm copying a version of that cropped to the bottom panel here:

The text is probably too long (could just use the first sentence, or even something shorter like "No security advisory coverage"?) but in general I think this is the kind of change we're looking for in this issue. And it could use the same design regardless of whether the project has updates available or not.

Projects that do have security advisory coverage don't need an indicator at all, as others have said above -- it doesn't add any particularly useful information. Yes, it is true that this would sort of be the opposite of drupal.org (which shows positive indicators for releases that have security coverage) but I think that's fine, since the purpose is different. The drupal.org pages are primarily designed for people who are installing new projects, so it makes sense for the icons to guide them to the "correct" thing to download. The Update Status page, however, is designed for people who already have the project installed on their site, so it makes sense for the icons to highlight cases that require extra attention.

yoroy’s picture

Status: Needs work » Needs review
FileSize
89.1 KB

We initially discussed a table based approach with additional columns but I couldn’t make it work.

1. Changed to a “box per module” design. The table-based approach isn't really up to fitting all the different types of things that we need to show per project
2. Moved the "Includes" bit right below the module name
3. We currently have two links to release notes, one to download. I removed the explicit "relase notes" link per release. Clicking the module version link gets you there as well.
4. The security coverage info is shown as a short sentence with a link. I left out the icon so that there's no competition with the actual status info icons.
5. I didn’t look into use of color to indicate status. I'd eventually like to see color used more sparingly than the current full row background fills.

What did I miss? :)

yoroy’s picture

FileSize
87.64 KB
japerry’s picture

Added a somewhat related issue.. where hopefully we'll be patching core soon to eliminate the experimental module warnings.

Looking at the screenshot #83, we see redundant , inactionable, text. As a site maintainer, what am I going to do with this? Its really unfortunate that we aren't instead showing some positive wording instead that shows which modules are covered by the security policy. Maybe even order them at the top or something.

yoroy’s picture

I *knew* I messed up something :)

I'm fine with switching this to positive messaging and labelling the projects that *do* have coverage. Then we'd have to match the messaging on Drupal.org as well. (Projects without any covered releases could then still have the 1 single warning)

Happy to revisit this, but so far did not get feedback on the overall proposed design.

drumm’s picture

Attached is a patch bringing in feedback summarized by #74, #83, and #86.

The new warning on the status report page:
Screenshot
Project-specific details have been removed.

The updated updates status page:
Screenshot

  • Reformatted to not be a table, this uses the admin_block theme function, which comes with the light grey background.
  • Rearranged the contents to match #83 and #86. I added the “Installed version” label because I thought the first version number needed some context.

Status: Needs review » Needs work

The last submitted patch, 87: 2766491.patch, failed testing.

japerry’s picture

Looking better! However, I'm still going to strongly argue that having the missing security coverage piece being a warning is too much for site owners, because warnings are supposed to indicate something that is actionable/fixable. This does extend to experimental modules as well, which also has too strong of wording and should be informational, unless we can find something better (suggestions maybe?)

But lastly, and maybe most importantly: My site is telling me that those who developed the site have done something potentially wrong. Along with the experimental modules (in which layout discovery should definitely be used right now, and is experimental for bad reasons IMHO), we cannot have sites contradicting what are considered module best practices within some of largest drupal development agencies in the world.

In a few years, this might not be a big deal. But right now, in Drupal 8, we cannot have warnings like this on the status page, because they are just plain misleading.

Alternatively, similar to experimental modules, I do think having some stronger wording during install is a good idea. Its important that site builders understand the potential ramifications of installing experimental and/or pre-release modules. But once the architectural decision is made, there is little reason to keep bugging the admin/user/future user about it...

hestenet’s picture

I'm glad to see we're closer to consensus here.

I think @DyanneNova's reasoning in originally suggesting the warning message on the status page is sound. #2766491-63: Update status should indicate security coverage

Also - it is incorrect to say that the message is not actionable.

While the message is not always actionable it may be actionable for some number of sites and users.

  • Not actionable - Enterprise client with a team that's made an architectural decision to use a beta version.
  • Actionable - Small developer/site builder is in the (non-ideal) habit of using prereleases - they might not know the best practices or risks - now they have a message on their site that helps them out.
  • Actioniable - Developer/site builder is slapping together a proof of concept/pre-production version of a site with drush/composer etc (i.e: not looking at project pages), they happen to choose a module without coverage when perhaps another similar module exists that is covered. The warning message gives them a reason to look.
  • Actionable - A site owner (the type who has no reason to use d.o themselves...) doesn't have ongoing support from their original site builder and, for better or worse, hasn't updated things in a while - a stable release with coverage is now available, but they're never going to look for one without messaging that tells them to do so.

I'm sure one could quibble with some of these scenarios - but the point is there are sites out there that are not the big enterprise sites with ready support from big shops/dev teams - and there are any number of ways that these sites could wind up with non-covered modules when that information is actionable.

And in all cases there's the minimum action of simply being aware of the risks of public disclosure. I think the current patch in #2766491-87: Update status should indicate security coverage accomplishes that without being overly frightening.

I'd really appreciate another review by @yoroy, but I think we're close to RTBC.

David_Rothstein’s picture

Those might be reasons for an informational message, but not a warning message. (Especially since the new design doesn't treat this as a warning condition on the Update Status page itself, just an informational condition there - why would we then go ahead and treat it as a warning elsewhere?)

I think discussion of a message on the Status Report, as well as of a confirmation message when enabling modules (from #89), would be better off discussed in a separate issue anyway.

***

As for the message on the Update Status page, it looks pretty good. However, I'm concerned that many of the changes are unrelated to this issue and not necessarily a good idea. We should not be changing things that don't need changing here, especially in Drupal 7. Two things in particular:

  1. 2. Moved the "Includes" bit right below the module name

    Why? This is taking the least important information and putting it near the top. This seems especially bad for Core (which as can be seen in the screenshot from #87 has a very long "Includes" list) because it pushes the important information way down to the bottom.

  2. 3. We currently have two links to release notes, one to download. I removed the explicit "relase notes" link per release. Clicking the module version link gets you there as well.

    I am concerned that no one will know that though. Personally I've always clicked on "Release Notes" myself, and I think there is some logic in having it as prominent as the "Download" link. Was the goal here to save space given the new "Covered by" text that's being added? Is there another way we can deal with that?

David_Rothstein’s picture

FileSize
77.2 KB
85.63 KB

Comparing the overall before and after screenshots (see below) this really doesn't feel like an improvement to me. The "after" screenshot (a) has way fewer visual cues to tell you which modules are up to date and which aren't (due to the removal of the background colors) and (b) has lots of extraneous text (including the "installed version" text plus the release date on an already up-to-date module, which doesn't seem useful to me and wasn't in the design either).

Again, I think it would be better to try to make the smallest possible changes that can be made to get this issue fixed.

David_Rothstein’s picture

FileSize
75.61 KB
85.44 KB

My previously-uploaded screenshots (in the above comment) were bad so here are better ones.

BEFORE:

AFTER:

yoroy’s picture

Thanks for a more detailed review @David_Rothstein :)

I would prefer to agree on the different kinds of changes needed in this issue. Implementing and fine-tuning a warning on a confirmation screen can be a separate issue. Deciding we want to do that in the first place, that would be good to do in here.

  1. I moved the "Includes" section right below the project name because it's as close to a "body" text we have for the "title" that is project name. That makes it a more logical grouping: first the information about the project (name, includes), then the actions you can take on it.
  2. I never read release notes, maybe that's why :). We could also keep the label "Download" and have that link to the release notes page, there's big, green download buttons in immediate view there. It would add a click compared to the current behaviour of the download link but that may be a worthy trade off? I agree that the linked version number is relatively obscure. Then we should remove it :)

In general I reshuffled things because there are potentially quite a lot of different things to communicate per project/release. I don't think we can just append another line of text to what's there now. Doing the minimal change here would amount to simply adding yet another line of text to each release. I feel we should and can do better than that.

Remember that my proposal was a wireframe. I think we're missing a visual design treatment because without the color coding and other queues the current patch makes things less quick to scan indeed.

japerry’s picture

FileSize
362.64 KB

I did a little bit of investigation to see how the Experimental warnings UX came to be. Turns out, there was no UX or really any community review other than Alex and XJM. So I don't think we should be relying on that UX as a good idea. In fact, I've suggested we remove it: #2880374: Experimental modules should not have warnings after being installed

Also - it is incorrect to say that the message is not actionable.

Disagree pretty strongly about those reasons for 'actions':

  • Small developers should be getting the message when they install the modules. This is where the education should occur. Once they install the module, there is nothing they can do short of remove the feature. This is not considered an action by most people.
  • First, there is no way to know what better module to use. We don't make suggestions on which modules are better than the ones they choose. Secondly, composer does warn which modules aren't covered under the security policy. But also, if a developer is building with drush/composer, we should be trusting that they've done some due diligence around their decision and not second guess it. Again, not really an action here.
  • Site owners need to be able to trust their site builder to be making the correct decisions. In d8 right now, the correct decision is to use modules not covered by the security policy. For modules that later on get full release updates, they will see an actionable option under the site updates page, which is wholly appropriate. Worse, if a site owner is being told the remove a module, they might do it without knowing the consequences, which then breaks their site.

Here is an example screenshot of what we could see for typical warnings pre-launch of a site:

You'll see something familiar here, all of these, except experimental modules, are reasonably expected to be actionable I do not consider uninstalling a module a reasonable action.

japerry’s picture

David_Rothstein’s picture

I would prefer to agree on the different kinds of changes needed in this issue. Implementing and fine-tuning a warning on a confirmation screen can be a separate issue. Deciding we want to do that in the first place, that would be good to do in here.

OK, can everyone here agree on an informational message on the status report page, rather than a warning message? (That is what #2880374: Experimental modules should not have warnings after being installed proposes for experimental modules also.)

We could also keep the label "Download" and have that link to the release notes page, there's big, green download buttons in immediate view there. It would add a click compared to the current behaviour of the download link but that may be a worthy trade off?

That works for me. I would not be surprised if someone complains about it, but I am OK with it myself :)

Remember that my proposal was a wireframe.

Hm, well I guess the wireframe was implemented in the patch... But if it was just supposed to be a wireframe, then yes, that makes more sense.

drumm’s picture

We could also keep the label "Download" and have that link to the release notes page, there's big, green download buttons in immediate view there. It would add a click compared to the current behaviour of the download link but that may be a worthy trade off?

That works for me.

Works for me too. Occasionally release notes pages have useful notes. Sending people to them is okay.

This patch makes that change and cleans up the tests. There are no visual changes for now.

OK, can everyone here agree on an informational message on the status report page, rather than a warning message?

Clear messaging was strongly requested from the security team point of view. For now, I left it as-is. We can wait and see where #2880374: Experimental modules should not have warnings after being installed goes.

drumm’s picture

Status: Needs work » Needs review

Forgot to set the status for testing.

yoroy’s picture

FileSize
147.96 KB

@ifrik and I discussed another possibility, which is grouping the projects in "covered" and "not covered" buckets on the page. This way it's not necessary to mention this information for each module.

Here's a more refined *wireframe*. I put the background colors back in:

yoroy’s picture

FileSize
148.2 KB
yoroy’s picture

Thinking about this in terms of minimal viable changes we can make. The goal of this issue is to indicate which modules are covered by the security advisory and which ones are not. This is important information but repeating it for every listed *release* of a module would mean adding a lot of repetitive text to the page.

So:

1. Must have: Group the modules that have available updates into 2 main buckets: covered and not covered. We'd still have to design how each of those headers look. But even when we'd leave the current table based display as is, this change alone would fulfill the must-have issue goal of indicating security advisory coverage.
2. The could-have would be to move away from the table based display and have boxes per project.
3. The nice-to-have then is to rearrange the information and links within each listed release.

I'm curious to hear whether people would agree with these priorities. If so, we can then design and write the specifics for the covered/not covered headings. This diagram draws a box around each of the two buckets but not sure that's actually necessary in the visual design.

David_Rothstein’s picture

I like that change when considered in isolation.

But there are opportunity costs to breaking the page up into those buckets. If you're moving away from a plain alphabetical listing, are those really the best buckets to use? Why not group by a more important attribute instead? (For example, putting modules that aren't up-to-date, and that have security updates which need to be applied, at the top of the page would probably be more logical - and would correspond more closely to how other pages such as the Status Report page at admin/reports/status are grouped.)

If the goal is just to reduce the repetitive security advisory text, shortening the text could be a simpler way to accomplish that... something like "Has security advisory coverage", for example.

drumm’s picture

FileSize
25.8 KB

This is a work in progress, only #98 with bringing back the background colors for security update status. (Security advisory coverage does not affect the background color.)

Depends on #2887860: Allow color-* to be used in admin blocks. This patch replaces table formatting with admin_block theming. The table had been a single column without headers, it wasn’t really being used.

drumm’s picture

If the goal is just to reduce the repetitive security advisory text, shortening the text could be a simpler way to accomplish that... something like "Has security advisory coverage", for example.

This was done on or before #98. The copy shown, as you can see in the issue summary screenshots, is “Covered by Drupal’s security advisory policy

The update status page with this patch has no information about the real risks of running non-covered releases.

drumm’s picture

repeating it for every listed *release* of a module would mean adding a lot of repetitive text

This information is per-release. For example, if your site has 8.x-1.0-beta3, with an upgrade to 8.x-1.0 available, that upgrade would bring your site into more security advisory coverage. Doing that upgrade might be nearly as important as an upgrade for a security announcement.

https://www.drupal.org/project/media/releases/7.x-2.0 is an example of this happening recently. That release had security improvements, but as the first stable release in the 7.x-2.x series, no security announcement was required.

drumm’s picture

Issue summary: View changes
FileSize
148.2 KB

Replacing the update status screenshot in the issue summary with the version from #104 with background color.

drumm’s picture

Issue summary: View changes
FileSize
158.21 KB
26.32 KB

Fixing a bug where the installed version sometimes was not shown. Otherwise, equivalent to #104

Showing the installed release information had been simply showing the version string. It is now using the full data structure to match the “Recommended version/Security update/etc” options below. But, I missed a place where update_calculate_project_update_status() needed to be sure to pass on the installed version’s release information.

drumm’s picture

On grouping the page - we should make sure the update status page always highlights available updates, security and otherwise.

Lack of security advisory coverage is important too. Those updates will include security fixes that aren’t called out by a security announcement. And the public issue queues for those projects will have security issues without fixes. Even if there isn’t an actionable upgrade, there is risk you should be aware of, or paying someone to be aware of.

That said, grouping by covered/not doesn’t seem like the right approach. That seems like it is prioritizing that above updates available.

drumm’s picture

FileSize
26.46 KB

Adding use Drupal\update\UpdateManagerInterface for the class constants for coding standards.

David_Rothstein’s picture

If the goal is just to reduce the repetitive security advisory text, shortening the text could be a simpler way to accomplish that... something like "Has security advisory coverage", for example.

This was done on or before #98. The copy shown, as you can see in the issue summary screenshots, is “Covered by Drupal’s security advisory policy”

My intention was to shorten it further. The difference is only a couple words, but every word counts... I feel like this is something I learned from @yoroy at some point :)

yoroy’s picture

Ok, if grouping by status is not viable then we add the information to each release. In as few words as possible :)

ifrik’s picture

Agreed - at this stage it is more important that users are aware whether modules are covered by the security advice or not. So the minimum viable change is to add that text to the page as it currently is, even if it's repetitive or doesn't look pretty.

Let's provide that information to users now - and change the display once somebody comes up with a good idea.

Related issue: the Help text for the Update module then need to be changed, to mention this additional information under "Checking for available updates"

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

drumm’s picture

Rebasing for 8.5.x

drumm’s picture

FileSize
26.53 KB

Minor update to keep up with a change in #2887860: Allow color-* to be used in admin blocks