1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
|
---
stage: Plan
group: Project Management
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
---
# Confidential issues
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/3282) in GitLab 8.6.
Confidential issues are issues visible only to members of a project with
[sufficient permissions](#permissions-and-access-to-confidential-issues).
Confidential issues can be used by open source projects and companies alike to
keep security vulnerabilities private or prevent surprises from leaking out.
## Making an issue confidential
You can make an issue confidential during issue creation or by editing
an existing one.
When you create a new issue, a checkbox right below the text area is available
to mark the issue as confidential. Check that box and hit the **Submit issue**
button to create the issue. For existing issues, edit them, check the
confidential checkbox and hit **Save changes**.
## Modifying issue confidentiality
There are two ways to change an issue's confidentiality.
The first way is to edit the issue and mark/unmark the confidential checkbox.
Once you save the issue, it will change the confidentiality of the issue.
The second way is to locate the Confidentiality section in the sidebar and click
**Edit**. A popup should appear and give you the option to turn on or turn off confidentiality.
| Turn off confidentiality | Turn on confidentiality |
| :-----------: | :----------: |
|  |  |
Every change from regular to confidential and vice versa, is indicated by a
system note in the issue's comments.
## Indications of a confidential issue
NOTE:
If you don't have [enough permissions](#permissions-and-access-to-confidential-issues),
you won't be able to see the confidential issues at all.
There are a few things that visually separate a confidential issue from a
regular one. In the issues index page view, you can see the eye-slash icon
next to the issues that are marked as confidential.
---
Likewise, while inside the issue, you can see the eye-slash icon right next to
the issue number, but there is also an indicator in the comment area that the
issue you are commenting on is confidential.
There is also an indicator on the sidebar denoting confidentiality.
| Confidential issue | Not confidential issue |
| :-----------: | :----------: |
|  |  |
## Permissions and access to confidential issues
There are two kinds of level access for confidential issues. The general rule
is that confidential issues are visible only to members of a project with at
least [Reporter access](../../permissions.md#project-members-permissions). However, a guest user can also create
confidential issues, but can only view the ones that they created themselves.
Confidential issues are also hidden in search results for unprivileged users.
For example, here's what a user with Maintainer and Guest access sees in the
project's search results respectively.
| Maintainer access | Guest access |
| :-----------: | :----------: |
|  |  |
## Merge Requests for Confidential Issues
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/58583) in GitLab 12.1.
To help prevent confidential information being leaked from a public project
in the process of resolving a confidential issue, confidential issues can be
resolved by creating a merge request from a private fork.
The merge request created will target the default branch of the private fork,
not the default branch of the public upstream project. This prevents the merge
request, branch, and commits entering the public repository, and revealing
confidential information prematurely. When the confidential commits are ready
to be made public, this can be done by opening a merge request from the private
fork to the public upstream project.
NOTE:
If you create a long-lived private fork in the same group or in a sub-group of
the original upstream, all the users with Developer membership to the public
project will also have the same permissions in the private project. This way,
all the Developers, who have access to view confidential issues, will have a
streamlined workflow for fixing them.
### How it works
On a confidential issue, a **Create confidential merge request** button is
available. Clicking on it will open a dropdown where you can choose to
**Create confidential merge request and branch** or **Create branch**:
| Create confidential merge request | Create branch |
| :-------------------------------: | :-----------: |
|  |  |
The **Project** dropdown includes the list of private forks the user is a member
of as at least a Developer and merge requests are enabled.
Whenever the **Branch name** and **Source (branch or tag)** fields change, the
availability of the target or source branch will be checked. Both branches should
be available in the private fork selected.
By clicking the **Create confidential merge request** button, GitLab will create
the branch and merge request in the private fork. When you choose
**Create branch**, GitLab will only create the branch.
Once the branch is created in the private fork, developers can now push code to
that branch to fix the confidential issue.
|
