A potential blocker for Drupal core migration to GitLab was identified at the infra panel at Chicago (and the question was also raised here: #3559846-14: Allow changing GitLab issues labels for all contributors).
There is a mapping of permissions between d.o. and Gitlab (see: #3586519-17: Migrate maintainers from Drupal.org projects as GitLab members):
“Write to VCS” grants the GitLab project developer role.
Having both “Administer maintainers” and “Write to VCS” grants the GitLab project maintainer role.
“Maintain issues” grants the GitLab project planner role.
Currently, the subsystem maintainers are granted Developer role on Drupal core project, see: #3392124: [policy] Subsystem maintainer permissions on GitLab
In Gitlab, each role, except the Guest, is able to see confidential (private issues), see: https://docs.gitlab.com/user/permissions/#project-planning
With the current settings, once the Drupal core is migrated to Gitlab, the subsystem maintainers will be able to see all confidential issues, which is not something they have a permission currently on s.d.o. (subsystem maintainers are added to Drupal core security issues only if the issue affect their subsystem, or if needed).
One proposed way forward (based on a Slack discussion) was to do an audit of all the things the people with that role use their permissions for (currently) and then try to find a way how to do it using bot integrations or custom UI on d.o. instead (like comment/resolve threads, edit issue summaries, re-trigger pipelines, ...).
Other options TBD.
Discuss possible options/solutions and implement it.
Comments
Comment #2
poker10 commentedComment #3
drummNot that it makes too much of a difference, but this is only for the initial confidential issue that is filed within the project itself. Once a confidential issue is opened, it is copied into the security team group, so the security team has access. All future discussion happens in that issue, which is only visible to the security team and invited individuals.
The initial report is indeed a confidential issue in the project itself, that follows GitLab permissions, https://docs.gitlab.com/user/permissions/#project-planning.
Notifications are sent when configured, so anything that deletes or clobbers the initial report would not be an effective solution.
GitLab does have custom project roles. The only way that would potentially work is if Guest plus some project permissions from https://docs.gitlab.com/user/custom_roles/abilities/ are what we want for subsystem maintainers.