Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • G GitLab
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Issues 51
    • Issues 51
    • List
    • Boards
    • Service Desk
    • Milestones
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar
  • Infrastructure
  • GitLab
  • Issues
  • #518
Closed
Open
Issue created Jun 23, 2021 by Emmanuele Bassi@ebassi👣

Adapt to GitLab's security issues workflow

The extant workflow for security issues in GitLab is fairly janky:

  1. create a private fork of a public project
  2. create a confidential merge request with the fix
  3. invite people to your private fork to do reviews and iterate over the fix
  4. merge the confidential MR into the development branch of your private fork
  5. make the confidential MR public
  6. merge the now public MR into the public repository
  7. 🎉

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.

Edited Sep 10, 2021 by Emmanuele Bassi
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking