Product discovery for confidential merge requests
Problem to solve
Not all code can be made public immediately. For instance, for security patches you want to keep these out of the main codebase until they are resolved completely. Or features that you want to launch secretly using a feature flag.
For public projects, the contents of the repository and merge requests can be seen by everyone making this impossible. A work around is to use a separate project, but this is not convenient. It requires manually merging between the two projects, creates duplication configuring CI and deployment which are otherwise configured the same, and creates inefficiencies for users having to switch between the two projects.
GitLab should provide a streamlined process for confidential branches and merge requests.
-
Use case: Security releases for GitLab – every month GitLab prepares security releases on a different GitLab instance. Confidential issues exist in the main GitLab projects, but then merge requests are made in a different location. This makes it hard to track progress and collaborate.
-
Use case: secret upcoming feature – an open source project might be working on a significant new feature that they do not want to announce publicly.
Further details
GitLab currently does security releases using a project on a separate GitLab instance, and is trying to move towards using a private project on GitLab.com. The target state is roughly:
- public
gitlab-org/gitlab-ce
- private
gitlab-security/gitlab-ce
(which is a fork of the public project)
Target audience
- Sasha, Software Developer, https://design.gitlab.com/research/personas#persona-sasha
- Sam, Security Analyst, https://design.gitlab.com/research/personas#persona-sam
Proposal
We should work out what the immediate workflow problems of the two project solution is, and develop a more ambitious long term vision for where we should go in the longer term.
Short term: two projects with streamlined workflows to prevent secure data being leaked
Challenges
- prevent data being leaked from the private fork to the public project
- single source of truth for issues
- divergence of branches, resolving conflicts
- duplication of settings
Long term: one project for public and private branches
Ambitious vision: one project
A new setting will be available in the Project Settings called Confidential branches. This should be similar to protected branches but define which branches are confidential (e.g. security-*
)
Like confidential issues, confidential branches can only be viewed by users with Reporter access or above.
A Confidential Merge Request can be created by:
- creating a merge request from a confidential issue
- creating a branch (e.g.
security-cve-123
) in the confidential namespace, pushing and creating a merge request
Note unless the target branch is confidential, the merge request will not be confidential.
Technically, the security of the confidential branches will be achieved by having a second repository within the project. The confidential repo will essentially be a deduplicated copy of the main repo using Git alternates, and push rules will prevent confidential changes being pushed to the main repo, and public changes being pushed to the confidential repo. Practically, this will be two remotes:
- default:
git@gitlab.com:gitlab-org/gitlab-ce.git
- confidential:
git@gitlab.com:gitlab-org/gitlab-ce.private.git
Product discovery objectives
- what does the workflow look like for GitLab.com security issues?
- how can we prevent people accidentally pushing security issues to the wrong remote? (e.g. the user forgets to name their branch
security-foo
and pushes) - how will we mirror changes from main repo to the confidential repo?