Since GitLab 8.6, in both Community and Enterprise edition, there is a small
checkbox available when you create or edit an issue, allowing you to mark an
issue as confidential.
In some ways it’s a simple feature, but there are complex considerations.
The main point is to keep the confidential issues secure.
However, taking care of those considerations caused some problems during
development which are typical when you develop a feature for a relatively
long time (in this case two weeks). We'll look at that in this feature highlight.
About Confidential Issues
In the course of maintaining a project, it may be necessary to keep some
information from public view. A typical use case for confidential issues would
be a security report. Different projects support different ways to report
security issues, so if someone needed to report a security issue, they would
- Follow the instructions for security vulnerabilities, if there are any.
- File an issue with their findings and a request to get in contact with the
- Find other means to contact the maintainer.
In general, most of the projects advise to not use the issue tracker, and
instead send an email to a specific email address. As you might imagine before
this release we, as an open source project, advised the same
security vulnerability disclosure in our contributing guide:
Please report suspected security vulnerabilities in private to
[email protected], also see the disclosure section on the GitLab.com website.
Please do NOT create publicly viewable issues for suspected security
This generated a lot of overhead.
Behind the scenes, when we got a security report email, we would immediately
create an issue in our internal issue tracker to discuss possible fixes. So in
that case, we needed to keep in track two issues trackers: a public one on
GitLab.com and another private. In addition, the process to report a security
issue would be more complex than it is now. First, you need to discover how to
report the issue, and then report the issue itself.
Now, with Confidential Issues, the reporter can mark an issue as confidential
when creating or editing an issue, and only project members can see the issue,
as well as those who are assigned to it. As it turns out, the process is
considerably easier, since reporters don't need to find how to report security
issues anymore, and we don't need to work on two different issue trackers for
the vulnerability disclosures.
When an issue is marked as confidential, it is only visible to the team members.
It will be hidden from the public view, which means the issue tracker, the
activity feed, the milestone views, the auto-complete options, etc. Even if you
@mention, and you don’t have explicit access to the project, you won't
receive any kind of notification (in this case emails, and todos).
Behind the scenes: Resolving merge conflicts as you go
While this is a simple feature, it created an interesting problem, and I'm not
Because it causes lots of concern about security, we needed to very careful
with this. I had the branch open for a relatively long time (about two weeks),
and over time, I was running into merge conflicts almost daily. My work was
affected by other features being developed at the same time, for example
subscribe to labels. This happens very often if you have a merge request open
for a long time.
I do try and avoid this when I can. I check everyday if my merge request has
conflicts and I resolve these as I work, that is, instead of waiting until
the final release to merge.
It also helps a lot to do development with automated tests. As you work in
parallel with other developers and constantly update the feature, you can tell
if something is going to break.
Normally, you don’t work a long time on issues like this but in this case it
was unavoidable due to the security nature of the feature. Again, using tests
made this a lot easier.
More about GitLab 8.6
This confidential issues feature is just one of the many recent changes in GitLab.
Find out more about our latest release, 8.6 with new improvements