Contrib.social

Make it obvious to end-users what to do if a packaged release contains insecure code

Open on Drupal.org →
Created on 9 December 2013, about 11 years ago
Updated 27 December 2023, 12 months ago

As pointed out by webchick at #2137095-44: Should supported releases be shown on downloads table even if it contains insecure modules? If so, how? → it's not obvious to end users what to do in the case that the latest release of a given distribution contains insecure code. #2152549: Regression: restore color-coding for update status on packaged release nodes → would certainly help, but that's not the whole story. Quoting Angie:

But just to point out that it's not just the lack of colouring, it's also the total lack of direction on the release notes page that's the problem.

- I'm directed to release notes which don't actually say anything about security. That's in a table far below.
- In said table, I can't easily see what's secure/what's not (will be fixed by #2152549: Regression: restore color-coding for update status on packaged release nodes )
- When I see what's insecure, there's absolutely no direction on what to do about it. What is secure? How do I get those things into the distro I'm downloading?

...all of that is on the available updates page. Maybe the follow-up, rather than wording tweaking, should instead be to make that table more useful a la the available updates page then?

Some possible ideas:

  1. #2152549: Regression: restore color-coding for update status on packaged release nodes →
  2. Inject a warning at the very top of the release node itself, sort of like we now do in the download table. Each release already knows its own update status, so it'd potentially just mean exposing this field and writing a field formatter that does the right thing based on the status (i.e. nothing if it's normal, <div class="warning"> if it's not-secure). This warning could link to a handbook page about the situation (instead of trying to write a Wall Of Text(tm) there).
  3. Have a "known issues" entity reference field on release nodes, let maintainers populate them to point to the "Roll X+1 release" issue to clear up the security warning, and if the field is blank, print a message to end-users that the maintainers might not know about this with a link to create a the appropriate issue.
  4. In the table of packages included within the release, for releases that aren't secure, include a link to the latest recommended release (like the core Update Manager's UI). I'm worried this will be too cluttered and overwhelming. Furthermore, I think it's really the responsibility of the distro maintainer to handle this stuff -- I'd rather we weren't punting to end-users to try to resolve this themselves.
  5. ?
✨ Feature request
Status

Closed: outdated

Version

2.0

Component

Packages

Created by

🇺🇸United States dww

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

Comments & Activities

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024