This repository was archived by the owner on Nov 18, 2021. It is now read-only.
Repository navigation
This repository was archived by the owner on Nov 18, 2021. It is now read-only.
private issues or pull requests for public repositories #37
Description
In the course of maintaing a project it may be necessary to keep some information from the public while a security issue or other scenario is worked on.
Users or organizations that pay for private repositories should be able to create or mark an issue or pull request as private, from there only users specifically mentioned in the issue would have access.
Special care would need to be handled for issue cross linking and other notifications.
Activity
isaacs commentedon Jun 17, 2013
People have pasted npm account details in github issues on more than one occasion.
👍
jzaefferer commentedon Jun 21, 2013
How do you prevent those credentials from being emailed as notifications when the issue is created?
tjfontaine commentedon Jun 21, 2013
No one is claiming you can put the cat back in the bag, but there are all sorts of reasons it's still a good idea to make it private after the fact, namely stopping the google indexing or the casual viewing
jzaefferer commentedon Jun 21, 2013
The owner can just edit to hide that cat. Is that not sufficient?
tjfontaine commentedon Jun 21, 2013
There are other use cases than merely the credential leak, consider if the repository is working through a security vulnerability.
shilad commentedon Aug 24, 2013
+1 for the possibility of using GitHub for students in my classes and pull requests as a mechanism to turn in / receive feedback on assignments. Right now I can't do this because a student's pull request would publicize solutions.
patcon commentedon Oct 16, 2013
Made a comment back to the OP, but lots of +1's in this highly retweeted post:
https://twitter.com/adam_baldwin/status/385389448965664768
+160?
tjfontaine commentedon Dec 12, 2013
oh god. no no no no,
stash commentedon Dec 12, 2013
+1 - vulnerabilities should be able to be disclosed responsibly in issues.
isaacs commentedon Dec 12, 2013
@substack Being able to share private messages in the clear is lovely and useful for many things. But it doesn't obviate the need for private issues. It is, at best, an awkward workaround for this problem. If GitHub wants to be a social network, then they should add standard social network features, like private comments.
Qard commentedon Sep 4, 2014
+1
There are many reasons we need this:
We currently have to maintain two repos, one private and one public, to keep sensitive issues private. It's incredibly awkward and means we have to create issues ourselves and manually report updates to the relevant customer, rather than them being able just view the issue themselves.
zryty commentedon Feb 13, 2015
+1
For creating - new checkbox: [x] This is security issue.
Old issues of course can't be completely removed, but is nice to have something like this. (Consider allowing access for issue creator - provide more details etc)
steelbrain commentedon Mar 16, 2015
v6ak commentedon Jun 7, 2015
Implementation by competitors:
Google Code allows that. I am not sure if this is allowed for all projects, but in Chromium, you can mark an issue as security issue, which causes it not to be publicly available. Google, however, sends e-mail notifications in plaintext.
Bugzilla also allows that. It is more advanced than at Google Code, because it does not send much details in e-mail notifications unless user has uploaded his public GPG key.
[Bug 1169291] (Secure bug 1169291 in Firefox :: General)”, that is no summary is provided in the e-mail), as the subject is never encrypted even when using GPG, but the e-mail body contains GPG-encrypted content.52 remaining items
gojanpaolo commentedon Sep 10, 2020
@hems would locking the conversation solve your use case?
0xdevalias commentedon Sep 10, 2020
I believe this issue relates more to wanting this sort of functionality:
gojanpaolo commentedon Sep 10, 2020
@0xdevalias I don't think @hems is pertaining to confidential or security vulnerabilities because there is an intent to release it to the public later on. (see quoted comment below with emphasis on bolded phrase)
Also, I'm NOT saying that this issue will be solved by locking the conversation. I only suggested locking the conversation to solve @hems particular use case...
hems commentedon Sep 10, 2020
i did not know bout this issue, it's a very interesting one, still does not solve my issue.
as spoken i would need something like "invisible" PR and "issues" and perhaps even invisible "branches", this way it would be possible to avoid having two repos - one public and one private for the same project.
merlinstardust commentedon Sep 10, 2020
I think what you want sounds a lot like unlisted videos on YouTube. The PRs, issues, and branches could still be linked to and accessed by anyone but you wouldn't see any of them show up just looking at the repo
moorereason commentedon Oct 28, 2020
I would like this capability so that reports of Code of Conduct violations could be made privately on a public repo.
Jonas-Sander commentedon Mar 1, 2021
We would like to switch form gitlab to github but private/confidential issues are one of the key missing features right now :/
chrisisbeef commentedon Apr 15, 2021
This is a show-stopper for any project with any level of appsec maturity using github issues at all IMO. Teams need a way to track internally and externally reported security issues or other sensitive issues; having issues be "private" or "cofidential" is foundational for that to happen. Only people with specific roles, or assigned / mentioned in a ticket should be able to see the ticket while it's open. Once a confidential or private issue is closed, it should become publicly available for viewing -- this is the key of responsible disclosure and remediation.
adzuci commentedon Apr 16, 2021
Does https://docs.github.com/en/code-security/security-advisories/about-github-security-advisories give you some of the things you might want?
chrisisbeef commentedon Apr 16, 2021
This is for already publicly disclosed vulnerabilities so it doesn't address the issue of having a way for project issues to be marked confidential, private, or hidden.
gaming-se commentedon Apr 18, 2021
After a Vulnerability is found its usually necessary to develop changes in the project, if the Vulnerability is public you have a race between hacker that might want to use the vulnerability to make a harmful thing and developers that try to fix it, it would be better to give the good guys more time to fix the issue. That's why some users want to have the ability to make issues or pull requests in private to the developers of a project.
techdragon commentedon Apr 22, 2021
Not at all @adzuci. There are many scenarios where something should be handled privately, that are categorically not security issues so while you can in theory build a workflow on top of miss-using the security advisory mechanism to make private forks and PRs... they are not the appropriate place for all such private matters. @moorereason raised the example of Code of Conduct violations, and I can think of several publishing workflows for otherwise open teams with blogs based on GitHub pages, where it would be beneficial to allow appropriate team members to collaborate on a private draft of new content, before it is merged, rendered and published.
ScriptAutomate commentedon Apr 27, 2021
Some related GitHub Support Community topics, where people are asking similar questions:
GitHub response to the ask on confidential issues:
I also don't see anything on the roadmap: https://github.com/github/roadmap/projects/1
azinit commentedon Jul 26, 2021
Still actual!!
achimnol commentedon Jul 27, 2021
While being open source projects, still there are cases that I need to make private issues to avoid exposing customer information under NDA. To handle such cases, I'm running yet another issue tracker aside GitHub and this makes me difficult to have a consistent holistic view of the projects.
I think it is okay to reveal the existence of private issues as references in public PRs or commit messages, or as jumps of the issue/PR number sequences.
GitHub's organization-level projects may be a workaround to have both private/public issues in a single view, but I'd like to keep them under a single repository instead of making another repository just for private issue tracking. (for consistent way of references, etc.)