Confidential issues
Report back in https://news.ycombinator.com/item?id=10628112
With private issues we can have people report security issues with issues instead of using email and then adding them to a different private repo.
http://corte.si/posts/hacks/github-browserstate/ "Add a mechanism that lets users report private bugs, visible only to the repo owners. There's just no excuse for the lack of a feature like this." => My proposal would be to have these issues visible to the author of the issue and all people with access to the repository. Basically they are hidden from guests. This is the same way that private repositories work.
We could consider also having internal issues that are visible to all people with an account on the server to make the issue visibility similar to repository visibility.
/cc @JobV @dzaporozhets
Activity
This is purely something interesting for the community side of GitLab, where one has many open source projecst. It makes sense for that, but adds complexity for everyone else. That makes that I'm not a big fan of the feature. But if it's just a small, unobtrusive checkbox...hmmmaybe we can make it work.
My proposal would be to have these issues visible to the author of the issue and all people with access to the repository. Basically they are hidden from guests. This is the same way that private repositories work.
That would defeat the point regarding security issues and does not work like private repos. Private repos are only visible on explicitly granted access, e.g. group or project member.
I propose that if we do this, there is only one option:
Make this issue private? yes/no.That option would:
- make the issue invisible for everyone,
- except people with developer permission for the project / group and up
- except the creator
- except anyone mentioned in the issue
This would add a lot of complexity to many things though, including activity feeds, milestones, issue weight sums and more.
Alternative solution: create a private repo for private issues and just let people email you.
This has as advantage that no load of complexity is added to GitLab, but is still a reasonable solution.
Alternative: private / internal / public issues.
I don't really see the point, besides the illusion of consistency. It would just be confusing who is able to see an issue for projects that are one thing vs issues another thing.
E.g. what would it mean to have an internal project with a public issue or a private project with a public issue?
@JobV You seem to respond to my also suggestion, I'm fine with not doing that. Can you please respond to my proposal: "My proposal would be to have these issues visible to the author of the issue and all people with access to the repository. Basically they are hidden from guests. This is the same way that private repositories work."
This is different from your proposal to require the developer level or higher, which I think is not needed, reporters on the repo should be able to see private issues.
@sytses I wrote something here, but it was not clear to me, so a correction:
I think anyone with a membership, except guests should be able to see the private issues. That means that these issues are invisible for people looking a public projects, but do not have a membership to those projects.
So I agree, but it must be clear that these are invisible in public projects as well, except members > guests. This distinction is not often made in GitLab.
Edited by 🚄 Job van der Voort 🚀This type of functionality would also allow customers to report bugs on the issue tracker of a company. In this case what they report is only visible to them and the company, not to other customers. This prevents problems of confidentiality. At any point the issue can be shared more widely.
It is tempting to name this private/public issues, but I'm very afraid of the name overlap with private/internal/public projects, which is an orthogonal concept. Another related but orthogonal to this concept are external users: https://gitlab.com/gitlab-org/gitlab-ce/issues/4009
I propose to name the functionality described in this issue: confidential issues. Non-confidential issues would be the 'normal' issues.
@dzaporozhets What do you think about making this an EE feature? Small on-premises installations are less likely to have people they have to hide things from I think.
Small on-premises installations are less likely to have people they have to hide things from I think.
@sytses I agree. Let's make it EE only
mentioned in issue #4707 (closed)
https://news.ycombinator.com/item?id=11091716 wants this in CE
Reassigned to @dbalexandre
@sytses move this to CE then? (i.e. change the title)
Edited by 🚄 Job van der Voort 🚀@JobV Why? The one user that mentioned this was using open source project as an example. Projects can be hosted on GitLab.com which is EE.
My votes goes towards doing this EE exclusive, as it always was.
I was asking because @sytses suggested this with:
We need this ourselves to give security issues more visibility. Now they sometimes are less visible on dev.
dev runs CE.
@JobV Thanks for the answer. I understood that more as a: "This will enable us to use gitlab.com for everything and we won't have the need to separate security issues to dev".
@marin I understood the same.
@sytses @marin @dbalexandre ah, I guess I misunderstood! So let's leave it as EE exclusive.
I would like to see this feature in CE (or both CE and EE). I can see a benefit for non-profit and small business projects having the ability to hide security related issues from certain roles. They do not always have the time to correct these bugs in the most timely manner.
@chrissnyder2337 This feature is mainly intended for open source projects. If you're a member, you will see the confidential issues. Hiding things from certain roles sounds like a different problem. For making sure things are prioritised, I recommend using labels and milestones.
@dbalexandre please take into account also hiding things like weight and issue count from the milestone overview for non-members.
Edited by 🚄 Job van der Voort 🚀@chrissnyder2337 This feature is mainly intended for open source projects.
Issues that are intended for open source projects should be in CE. Let me base an argument from (what I understand to be) the official GitLab policy of deciding between EE/CE for features:
CE will have all the features that are essential to running a large ‘forge’ with public and private repositories
I think reporting of security vulnerabilities meets this test. Although it can be argued, that e.g. GitHub do not provide this, so it is not essential in that sense, that people somehow get by without it. But I think that says more about GitHub than anything. To me, a way to disclose a vulnerability in a responsible way is important.
When we make new features we ask ourselves, is this feature much more relevant for organizations that have more than 100 developers? If the answer is yes the feature is likely to be exclusive to EE.
I don't know what is "much more relevant" but libsodium is a good example of a project that desperately needs a feature like this and they have a lifetime of 46 contributors.
An organization with more than 100 developers probably has some other way to organize security issues, and may be skeptical of placing security-sensitive information into an RoR application. This is the case for one Fortune 500 I have personal knowledge about. So I don't believe large organizations would especially use this feature. I do believe security-focused open-source projects would.
We always make sure that CE can do all essential things
I believe reporting security issues in a confidential way is an "essential thing" in CURRENT_YEAR.
In summary I believe the stewardship document clearly supports CE for this feature. If somebody thinks it better supports EE, or believes the stewardship document is the inappropriate guideline for this situation, I would be interested to know why.
The term "confidential" can be used to mark classified material. (https://en.wikipedia.org/wiki/Classified_information_in_the_United_States#Confidential)
As a result, the “Confidential Issues” feature could present a problem for folks that use classification markings.
I know the name has already changed once from "Private Issues" to "Confidential Issues". I respectfully ask that the name "confidential" be reconsidered. I humbly suggest the following alternatives:
- Controlled
- Discrete
- Guarded
- Limited
- Restricted
@mp5730 Thanks for your careful comment. I must say that I don't like the alternatives very much. "Members only issues" is the best I can think of but that doesn't sound good either. I say we keep it confidential, at least these issues should comply with the definition "This is the lowest classification level of information obtained by the government. It is defined as information that would "damage" national security if publicly disclosed, again, without the proper authorization." :)
@JobV I'm torn if this should be EE or CE. If we want major open source projects to self-host with CE this would be an awesome feature for them to have. So I say CE.
@sytses thank you for taking time to review my comment.
@sytses I understand. My counter argument would be GitLab.com running EE, but I also realise that doesn't cover all cases.
I'll see whether I can bring more value to EE with other features.
Edited by 🚄 Job van der Voort 🚀mentioned in issue gitlab-com/marketing#11 (closed)
mentioned in issue gitlab-com/blog-posts#163 (closed)
mentioned in merge request !3282 (merged)
Status changed to closed by merge request !3282 (merged)
mentioned in commit 9813eac5
mentioned in commit cf52a9b4
mentioned in issue #14567 (moved)
mentioned in issue #14787 (closed)
mentioned in merge request !3471 (merged)
mentioned in commit 0c0ef7df
Mentioned in commit pfjason/gitlab-ce@cf52a9b4
Mentioned in commit pfjason/gitlab-ce@9813eac5
Mentioned in commit pfjason/gitlab-ce@a88a6d4b
Mentioned in commit pfjason/gitlab-ce@0c0ef7df
@mvdan Currently there is no way to disable confidential issues. Could you create another issue with this proposal? Thanks :)
Mentioned in issue #23296 (moved)
@dbalexandre done!
mentioned in merge request !14785
