Decide which labels are needed for

Created on 16 April 2025, about 2 months ago

Problem/Motivation

In s.d.o, we currently have these statuses:

  • Needs triage
  • Needs work
  • Needs review
  • Needs maintainer response
  • Needs team response
  • Needs reporter response
  • Needs public followup
  • Reviewed & tested by the community
  • Ready for SA to be Published
  • No maintainer response (unsupported)
  • Postponed
  • Closed (fixed)
  • Closed (can be public)
  • Closed (duplicate)
  • Closed (won't fix)

In Gitlab, these labels are set currently:

  • D7 affected (Tracking for D7ES vendors)
  • D7 needs evaluation (Tracking for D7ES vendors)
  • D7 only (Tracking for D7ES vendors)
  • Needs attention (Automatically added when an issue has not had a timely response)
  • Needs maintainer response
  • Needs public followup
  • Needs reporter response
  • Needs review
  • Needs security team response
  • Needs work
  • Project to be unsupported
  • Security advisory drafted (Automatically added when a security advisory draft is created on Drupal.org)
  • Security advisory needed (Will prompt maintainers to draft a security advisory)
  • Security advisory published (Automatically added when the security advisory is published)
  • Security risk Critical (Automatically updated with the risk score from draft security issues)
  • Security risk Highly critical (Automatically updated with the risk score from draft security issues)
  • Security risk Less critical (Automatically updated with the risk score from draft security issues)
  • Security risk Moderately critical (Automatically updated with the risk score from draft security issues)
  • Security risk Not critical (Automatically updated with the risk score from draft security issues)
  • Security status can be public (A security fix is not needed, further work can happen in public issues)
  • Security status evaluating to be public (2 weeks are allowed for security team feedback on potentially handling the issue in public)
  • Security status unvalidated (The issue is newly reported, the first step is to validate the issue)
  • Security status validated (It's been confirmed that an issue is in fact valid)

-----------------

The missing original statuses are:

  • Reviewed & tested by the community
  • Ready for SA to be Published
  • Postponed
  • Closed (duplicate)
  • Closed (won't fix)

Proposed resolution

Decide which additional labels we need to add and add them.

📌 Task
Status

Active

Version

1.0

Component

Security advisories

Created by

🇸🇰Slovakia poker10

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

Comments & Activities

  • Issue created by @poker10
  • 🇸🇰Slovakia poker10

    My thoughts regarding the missing statuses:

    Reviewed & tested by the community - I think that we discussed to use milestones to schedule releases. So adding an issue to a milestone can be probably considered as RTBC?

    Ready for SA to be Published - We used this status when maintainers actually committed the fix and created release. Can this be automated somehow, so that we are notified about new private releases in the Gitlab issue? If so, then web probably do not need this?

    Postponed - Not sure how to label such issues. Probably need to add this?

    Closed (duplicate) - We can link another issues in Gitlab, but there are only three options: relates to, blocks, is blocked by. If it will be sufficient to mark it as "relates to" and close it with a comment that it is a duplicate, then we probably do not need this label.

    Closed (won't fix) - Not sure how to label such issues. Probably need to add this?

  • 🇺🇸United States drumm NY, US

    Ready for SA to be Published - We used this status when maintainers actually committed the fix and created release. Can this be automated somehow, so that we are notified about new private releases in the Gitlab issue? If so, then web probably do not need this?

    📌 Update automated messages in Security Team's Gitlab Active did automate this, https://git.drupalcode.org/project/drupalorg/-/commit/47f37bb9 is the message added. It does not currently add a label. It was not working for the one_time_password issues since the advisories weren’t drafted starting from the GitLab issue, so there was no link from the advisory to the issue.

    Ready for SA to be published also needs the advisory to be drafted. I think what I’ll add is:

    • When a release is made, also add a label that the security release is done
    • Add a “Ready to publish” label (trying to keep labels as concise as they can be)
    • When an issue has both release done & advisory drafted, automatically add ready to publish. There isn’t a security team member has approved the SA draft state, but I think that’s fine to leave loose, as it will get a final review on security release Wednesday

    We can add additional daily notifications leading up to the scheduled security release date, if either tag is missing. Those can be drafted in 📌 Update automated messages in Security Team's Gitlab Active or a separate followup

  • 🇺🇸United States drumm NY, US

    Reviewed & tested by the community - I think that we discussed to use milestones to schedule releases. So adding an issue to a milestone can be probably considered as RTBC?

    I think we do want to add a label, that can have an automated response to tell everyone the next steps. That will be a bit better UI, labels are easier to remember and look for, and there is sometimes negotiation around which Wednesday a maintainer wants, or the team coordinating with something else. We could have the automation follow up if a ready issue is not assigned a milestone within a certain amount of time.

  • 🇺🇸United States drumm NY, US

    Closed (duplicate) - We can link another issues in Gitlab, but there are only three options: relates to, blocks, is blocked by. If it will be sufficient to mark it as "relates to" and close it with a comment that it is a duplicate, then we probably do not need this label.

    Closed (won't fix) - Not sure how to label such issues. Probably need to add this?

    We should add both of these, I imagine they will be useful for retrospectives.

    • drumm committed 10925629 on 7.x-3.x
      Issue #3519588: Add a label when a security release is made
      
  • 🇺🇸United States drumm NY, US

    The missing statuses are filled out now:

    • Reviewed & tested by the community → Security status::reviewed & tested
    • Ready for SA to be Published → Security status::ready to be published
    • Postponed → Security status::postponed
    • Closed (duplicate) → Closed::duplicate
    • Closed (won't fix) → Closed::invalid, potentially might be other statuses

    And what I mentioned in #5 is done by https://git.drupalcode.org/project/drupalorg/-/commit/109256299611a258d8... & https://git.drupalcode.org/security/triage/-/commit/cc6e081e6ab08d16f49b...

    So I think everything we’ve thought of has been followed up on.

Production build 0.71.5 2024