Adapt to GitLab's security issues workflow
The extant workflow for security issues in GitLab is fairly janky:
- create a private fork of a public project
- create a confidential merge request with the fix
- invite people to your private fork to do reviews and iterate over the fix
- merge the confidential MR into the development branch of your private fork
- make the confidential MR public
- merge the now public MR into the public repository
🎉
Sadly, GNOME falls face first at the very first step: we don't allow the creation of private repositories. Of course, we could ask the GitLab admins to turn a fork under a certain user's namespace private, but that only increases the jankiness of the whole process.
One possible solution, adapted from GitLab's own process, is to have a separate group, or sub-group, that allows GNOME maintainers to create private forks of projects under the GNOME group. Still janky, but at least it follows an established workflow, at least until GitLab figures out something better, and avoids homegrown solutions, like reviewing patches attached as files to confidential issues.
Ideally we want only active GNOME maintainers to be able to perform a private fork for security-related issues; this means creating a (sub-)group that does not have blanket permissions inherited from LDAP. Maintainers would then be allowed to add GNOME and non-GNOME users (using the Reporter level) to the private fork using the regular GitLab permission UI.
To sum up:
- create a new "GNOME Security" group, either at the top level or as a sub-group of the "GNOME" group
- only allow people listed in a project's DOAP to fork a repository under "GNOME Security"
- do not grant blanket Maintainer/Developer permissions to everyone under the "GNOME" group to projects under "GNOME Security" group
- project maintainers are Owners/Maintainers of the forked project, and can add GNOME and non-GNOME people to it at the Reporters level
After this, we're going to have to document the expected workflow on our maintainers documentation.