Clarification of "insecure" versus "unsupported"

Problem/Motivation

Here is my understanding of the current policy:

Security issues are discussed/fixed in private. Announcements/fixes are released according to a schedule, with a patch release separate from any other fix so a low risk of applying. Any earlier releases are marked "insecure". It is urgent for sites to upgrade because a vulnerability is now public.

On the other hand, releases can become unsupported at the maintainers discretion. There is an increasing frequency of contributed modules creating a new branch then very swiftly marking the old one as unsupported (today "Smart Trim"; recently "Devel"). Given this is a major/minor release, potentially not reversible and not back-compatible, it's high risk to apply it in a rush. It's not urgent for sites to upgrade because there is no known vulnerability.

Unfortunately, the Drupal update module treats these two cases in the same way: there are prominent warnings on the site, and an email is sent daily if notifications are configured for "Only security updates".

A modest complexity Drupal site likely has a high frequency patch releases. Hence sites typically roll out releases on a scheduled basis, e.g. monthly. This policy seems entirely reasonable as the outdated patch releases don't suddenly become dangerous, even though they aren't current and won't receive support.

Is a minor release any different? Do we really have to rush to updated outdated minor releases? I have seen several problems on live sites through rushing to respond to unsupported warning emails.

Proposed resolution

1) Please can the security team comment/confirm in general?

2) I am considering a policy of treating "not supported" (UpdateManagerInterface::NOT_SUPPORTED) exactly the same as "not current" (UpdateManagerInterface::NOT_CURRENT). Therefore I have a specific question please:

Specifically, for a project with security coverage enabled, and a release without the "Insecure" tag, can we rely that there is no public vulnerability? This would include the following cases:

• If a security issue is fixed in a newer branch, but not in the older branch then all releases for the older one would be marked insecure.
• If an entire project becomes unsupported because of an unfixed security issue, then all releases would be marked insecure.

3) If YES to question 2, then would the security team support a request to change the behaviour of the Drupal update module? For example there could be 3 thresholds for notification: all; unsupported&security ; only security.

Many thanks

Remaining tasks

User interface changes

API changes

Data model changes