Support confidential issues in git.drupalcode.org for security team triage

The initial work in the MR now handles new issues being filed:

And the moved issue currently looks like this:

Adding note that migration needs to happen.

> Migrate existing security issues. Do we need closed issues, or lose those forever?

I think we need the closed issues. As a general rule, I hate to throw away information.

If an issue was considered a valid security issue, then fixed, then some of the important information is in the public SA. Even then, a lot of details about the possible exploit are only in the issue (now closed).

If an issue was considered not to be a valid security issue, then at best we have a comment in a public "hardening" issue. The discussion and the details are only in the issue (now closed). We often look for old issues similar to newly created ones: "in previous issues very similar to this one, we decided to fix them in public because ...".

Agreed closed issues need to be migrated.

Did anyone open a feature request in gitlab to have a concept of a "security" role for users to be able to access all security issues?

Did anyone open a feature request in gitlab to have a concept of a "security" role for users to be able to access all security issues?

No, that didn’t happen. GitLab has only recently added custom admin roles, https://docs.gitlab.com/user/custom_roles/#custom-admin-roles, which might get us partway there.

Security issues will need private forks regardless, so private MRs can be used for review and testing. Putting those private forks under https://git.drupalcode.org/security takes care of giving the security team access, and the group labels, milestones, etc keep everything organized the same way. Even if there was a good way to give security team members access to all confidential issues, that is only partway there.

Documentation for this is started at https://www.drupal.org/drupal-security-team/security-team-procedures/sec... →

Remaining work:

• Set up the GitLab triage bot in a git.drupalcode.org repository with GitLab CI running the schedule, either using a new branch of https://www.drupal.org/project/securitydrupalorg → or a fresh project
• More documentation, including how to publish a security issue, and triage duty
• Test with security team members
• Complete 📌 Move security advisory drafting to www.drupal.org Active to allow project maintainers access to draft security issues
• Make the https://git.drupalcode.org/security/issues/-/issues project public, so anyone can report issues
• Migrate all security.drupal.org issues

I believe the main work left is to migrate the issues. As far as I'm aware, the new setup is feature-complete enough.

And we can open this process to everyone for more testing, we don’t need to complete the migration for the new process to be the default.

Are we worried about the sdo issue IDs being retained on gitlab?

In https://git.drupalcode.org/security/24-drupal-security/-/issues/1, we discussed a problem in the 11.x branch that did not exist in any released version of Drupal core. The issues that led to that problem were reverted, so the problem will never be part of a release.

I know that someone reading that can search for reverted issues and figure out where the problem was, but the problem has been fixed so I am not worried about mentioning it on this public issue.

The question for this issue is what label to attach when closing the private issue. I chose Closed:public, but I would have liked the option Closed:outdated. Should we add such a label?