Contrib.social

Develop and publish policy regarding missed SA notices

Open on Drupal.org →
Created on 22 March 2022, over 2 years ago
Updated 9 December 2024, 13 days ago

Problem/Motivation

During the January 26th 2022 'mass drop' of modules as unsupported the 'colorbox_node' module was marked unsupported for security issues, see https://www.drupal.org/node/1580102/revisions/view/9850899/12531683 → for confirmation.

A similar named module 'colorbox' was also included during the drops of January 26th see https://www.drupal.org/node/632214/revisions/view/12483569/12531845 → .

The error was mentioned to and acknowledge by security team members via Slack on February 2nd and February 10th.

I believe this was an honest error due to the large number of modules and having a set of modules similarly named causing no public SA notice to be published.

Since the Security Team has not resolved the situation for the module it appears either a policy on how to handle the situation OR introducing automation with technical lockouts (automate the publishing of the release, marking the module insecure, and publishing the SA notice to not require manual interaction) may be required.

Classifying as Major as it has significant repercussions for consumers of the SA Notice system(not made aware of a security vulnerability, and no SA# assigned) however it has a workaround of using the update feed to see when a release status has changed.

Proposed resolution

Develop a policy on how to publish a missed SA notice and required actions and responsibilities of the security team when made aware of such an error.

Remaining tasks

TBD

User interface changes

TBD

API changes

TBD

Data model changes

TBD

📌 Task
Status

Active

Version

1.0

Component

Security Working Group (policy questions)

Created by

🇺🇸United States cmlara

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

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment 13 days ago →
    🇺🇸United States greggles Denver, Colorado, USA

    Has this situation come up again?

    It seems uncommon enough that more documentation is not warranted.

  • Comment 12 days ago →
    🇺🇸United States cmlara

    It seems uncommon enough that more documentation is not warranted.

    I would suggest that is exactly why this should have documentation. You do not want to be writing your "(Emergency) Response Procedures" in the middle of a situation, you want them documented before the situation so that you "pull the binder off the shelf" and start following what has already been written.

    As long as we allow human error as a variable the risk of recurrence is there.

    Quick slack search:
    https://drupal.slack.com/archives/C5B7P7294/p1723053635495029?thread_ts=...
    SA was published to D.O. but not announced to mailing list, not as significant as what started this thread, however it is closely related as it is part of the 'publishing' stage of Drupal Advisories and provides evidence the human error factor is still occurring.

    I would have to dig deeper, however part of this has also been that many of us are now scrutinizing the security team's every action and flagging the issues publicly in the #security-team room when faults happen in the release cycle (Failing to publish a release, failing to publish the SA even though its been linked in the room, the SA being released to Composer when its not available on D.O.) etc. This does not mean the issue has disappeared nor is it a reliable solution.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024