Skip to content

GitLab Next

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
GitLab FOSS
GitLab FOSS
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 0
    • Merge Requests 0
  • Requirements
    • Requirements
    • List
  • Security & Compliance
    • Security & Compliance
    • Dependency List
    • License Compliance
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
  • GitLab.org
  • GitLab FOSSGitLab FOSS
  • Issues
  • #58583

Closed
Open
Opened Mar 06, 2019 by James Ramsay@jramsay☀Developer

Creating merge request from a confidential issue on a private fork

  • Backend weight: 3
  • Frontend weight: 3

Problem to solve

As an engineer working on an open source project, when I am assigned a confidential security issue there is no built in workflow for handling this. I need a way to work on my fix privately, and then merge it into some other confidential place so that the security issue isn't leaked in the process of fixing it.

GitLab should make sure the easiest, most obvious workflow to fix the confidential security issue is a secure workflow.

(Note, this feature is only relevant to public and internal projects, since marking an issue confidential in a private project only prevent guests from seeing the issue, and guests are already prevented from seeing the repository and merge requests, so there is no need to resolve the confidential issue in a different project)

Further details

This feature presumes a confidential fork has already been created (e.g. gitlab-org/secure-ce would be a private fork of gitlab-org/gitlab-ce)

Proposal

When viewing a confidential issue, I should be able to click Create confidential merge request to help me create a branch and/or a merge request in the private fork.

User has access to 1+ private forks in the same namespace User has access to 1+ private forks in a different namespace
The dropdown and submit button are green (success) because there are no negative consequences. We pre-select private forks in the following order: 1) fork in current group/namespace; 2) fork in sub-group; 3) fork in parent group; 4) fork in user namespace
If the private fork is in a different namespace from the original project, the submit button is orange (warning) to indicate 'attention-required'. Below the submit button we highlight the potential negative consequences of the user's action before they proceed.
image image
  • The Create confidential merge request button should:
    • automatically create a branch in the private fork (e.g. secure-ce) of the original project (e.g. gitlab-ce)
    • automatically create a merge request from the new branch (secure-ce:fix-1234) to the default branch in the private fork (secure-ce:master)
  • The Create confidential merge request button should only be available if:
    • there is already a private fork in the same namespace of the original project (e.g. secure-ce must be in gitlab-org), or
    • there is already a private fork in a different namespace: warn the user that they may leak confidential information, since the private fork may have members outside the original project group.
  • If there are multiple eligible forks, allow the user to select which fork to use.
  • The project fork dropdown shows the fork's visibility (in this case, only private forks) with an icon, to re-assure the user and confirm their visibility.
  • The ? icon has a More on confidential merge requests and branches tooltip and links to the docs in a new window.
  • We have to fix possible overflowing translations of the dropdown label! 🌍
  • Like a normal branch/MR, add system notes to the confidential issue pointing to the forked project.

Links / references

Edited Jul 03, 2019 by Pedro Moreira da Silva
Assignee
Assign to
12.1
Milestone
12.1 (Past due)
Assign milestone
Time tracking
None
Due date
None
Reference: gitlab-org/gitlab-foss#58583