Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

private issues or pull requests for public repositories #37

Open
tjfontaine opened this issue Jun 17, 2013 · 69 comments
Open

private issues or pull requests for public repositories #37

tjfontaine opened this issue Jun 17, 2013 · 69 comments

Comments

@tjfontaine
Copy link
Collaborator

@tjfontaine tjfontaine commented Jun 17, 2013

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.

@isaacs
Copy link
Owner

@isaacs isaacs commented Jun 17, 2013

People have pasted npm account details in github issues on more than one occasion.

👍

@jzaefferer
Copy link

@jzaefferer jzaefferer commented Jun 21, 2013

How do you prevent those credentials from being emailed as notifications when the issue is created?

@tjfontaine
Copy link
Collaborator Author

@tjfontaine tjfontaine commented 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
Copy link

@jzaefferer jzaefferer commented Jun 21, 2013

The owner can just edit to hide that cat. Is that not sufficient?

@tjfontaine
Copy link
Collaborator Author

@tjfontaine tjfontaine commented Jun 21, 2013

There are other use cases than merely the credential leak, consider if the repository is working through a security vulnerability.

@shilad
Copy link

@shilad shilad commented 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
Copy link

@patcon patcon commented 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?

@substack
Copy link

@substack substack commented Dec 12, 2013

$ npm install -g cipherhub
$ cipherhub -d <<<hEK3gIQAwxnd2cFB8b+yO/zak/4yHMVeTi4ohpPkv1zoBFpHDoSr8aFn1jjApctgHUxilqRk5gssf0AUsHVJa2MXZ9HB31/DorVqul3h/mAKRXwonvITEmusQ/hTcSmk3Pc12/mtSb7m23YE5vx2h5Ntc7sxw8Ar6fXfq1s2KxP5OqfaoxGytVQ7PfO5/iD1fvqQKtrk32pQgTt/5+eNqcNgtPGCrrg4Ohm9OTlwkYKNdbGDyZrpfmch6xiC5QlBws+OkAAQbPgFeGljBm8Wnh2zRpzJKgCaE0cJBkmQNlL3lD1bo62nLm/OLzn2uQVpNByIMMX8yzKwlZTO2oWu6Q==
@tjfontaine
Copy link
Collaborator Author

@tjfontaine tjfontaine commented Dec 12, 2013

oh god. no no no no,

@stash
Copy link

@stash stash commented Dec 12, 2013

+1 - vulnerabilities should be able to be disclosed responsibly in issues.

@isaacs
Copy link
Owner

@isaacs isaacs commented 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
Copy link

@Qard Qard commented Sep 4, 2014

+1

There are many reasons we need this:

  • Tracking fixes for security vulnerabilities
  • Tracking issues for customer bugs that require log data with security sensitive data in it.
  • Customers often don't want it to be publicized that our product is running in their network for fear it could be an attack target.

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
Copy link

@zryty zryty commented 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

This comment was marked as spam.

@v6ak
Copy link

@v6ak v6ak commented 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.

  • When GPG key is not configured in user's profile, the e-mail contains just (as far as I remember) bug number + bug link, category classification, identification of user who made a change and a note about GPG.
  • Once a public GPG key is uploaded, the e-mail subject is still rather brief (e.g. “[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.
@cirosantilli

This comment was marked as spam.

1 similar comment
@ettisan

This comment was marked as spam.

@bortels
Copy link

@bortels bortels commented Jul 15, 2015

+1

I found a fundamental security issue in a somewhat-popular (30,000+ users) project, and have no way to privately contact the author to tell them about it. Posting an issue in public is tantamount to giving the hackers a free pass. As I stands, I am forced to troll thru google hoping this person has exposed an email address somewhere.

It would be fundamentally useful to have a "send private note to project maintainer" mechanism of some sort.

@dychen

This comment was marked as spam.

1 similar comment
@iamerikjolson

This comment was marked as spam.

@Joellenicelook

This comment was marked as spam.

2 similar comments
@boskya

This comment was marked as spam.

@c-bik

This comment was marked as spam.

@brackendawson
Copy link

@brackendawson brackendawson commented Sep 21, 2015

+1 for responsible disclosure.

@mcanthony
Copy link

@mcanthony mcanthony commented Sep 30, 2015

I think there are many use cases for this that are not security focused. Not to say that is not a big use case, just that it is one of many so if this feature was added I don't think it's scope should be narrowed down to tagging things as vulns.

For instance some people who believe such things should be made immediately public (for the sake of argument) and such people may not want issues filed under this tag to be hidden by default.

Ideally a generalized option to submit an issue as "private" should be available and used at the discretion of either the OP or the maintainers. This means that the OP (which does not have access to add labels) would be able to avoid submitting something they know to be sensitive, in the process ringing a bell that simply cannot be (completely) unrung by a maintainer eventually labeling the issue as private/sensitive. Adding this feature would also address a few other privacy (and vanity) related concerns regarding the publication of contributions on a users public-facing profile page.

I don't see this as something that should be exclusive to paid-members only since it's use case are only applicable to public facing repos anyway.

In my view the availability of this option to all Github users does not in any way undermine the usefulness of a paid account. In other words this option does not offer anything that would preclude a user or organisation from needing paid services.

@abrookbanks

This comment was marked as spam.

@harry-m

This comment was marked as spam.

1 similar comment
@sibblegp
Copy link

@sibblegp sibblegp commented Nov 7, 2016

+1

@kode54
Copy link

@kode54 kode54 commented Nov 17, 2016

Requesting this, and with a suggestion to make this a relevant post. A friend wants to be able to have a public repository, but only wants issues to be posted by contributors to the repository. Mainly because they want constructive bug reports from an informed user base, not "this is broken, please fix it".

@levithatcher
Copy link

@levithatcher levithatcher commented Feb 13, 2017

+1 It'd be helpful for the dev team to be able to discuss things in a non-public way.

@bluepnume
Copy link

@bluepnume bluepnume commented Feb 28, 2017

Would really appreciate this at https://github.com/paypal. We're trying to run https://github.com/paypal/paypal-checkout as an open-source repo, but would be awesome to have a way to track security issues privately until they're fixed. This would enable us to use github for 100% of our issue tracking.

@hai-nguyen-van

This comment was marked as spam.

@Micr0Bit

This comment was marked as spam.

1 similar comment
@ghost
Copy link

@ghost ghost commented Jun 20, 2017

+1

@baremetaldude
Copy link

@baremetaldude baremetaldude commented Jul 11, 2017

It may be helpful if I want to provide remote access to virtual machine for project maintainers to fix platform-specific bug

@ikalogic
Copy link

@ikalogic ikalogic commented Jul 17, 2017

I want this too.

@rgerhards
Copy link

@rgerhards rgerhards commented Jul 20, 2017

I actually consider this so important that I would actually sign up for a priced plan just to get it.

@ewengillies

This comment was marked as spam.

1 similar comment
@Codebot2455

This comment was marked as spam.

Repository owner locked and limited conversation to collaborators Aug 2, 2017
@TPS TPS added opsec privacy labels Sep 15, 2019
Repository owner unlocked this conversation Aug 4, 2020
@PirxDanford
Copy link

@PirxDanford PirxDanford commented Aug 27, 2020

We are also looking into disbanding our bugtracker and switching 100% to github issues, but especially for security related concerns private conversations are a must have.

@hems
Copy link

@hems hems commented Sep 10, 2020

Also would like to have private issues and private PRs, this way we can have an open-source library with internal discussions and tasks being managed on GitHub issues before releasing them to the public.

@gojanpaolo
Copy link

@gojanpaolo gojanpaolo commented Sep 10, 2020

@hems would locking the conversation solve your use case?

@0xdevalias
Copy link

@0xdevalias 0xdevalias commented Sep 10, 2020

I believe this issue relates more to wanting this sort of functionality:

  • https://docs.gitlab.com/ee/user/project/issues/confidential_issues.html
    • Confidential issues are issues visible only to members of a project with sufficient permissions. Confidential issues can be used by open source projects and companies alike to keep security vulnerabilities private or prevent surprises from leaking out.

  • go-gitea/gitea#3217
    • This is a most for organizations that handle coordinated disclosure and patching of security vulnerabilities on public open-source projects. It would allow discussions to go on between the early disclosure and the full disclosure dates. The issue could later be made public at the date of full disclosure.

@gojanpaolo
Copy link

@gojanpaolo gojanpaolo commented 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 would like to have private issues and private PRs, this way we can have an open-source library with internal discussions and tasks being managed on GitHub issues before releasing them to the public.

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
Copy link

@hems hems commented Sep 10, 2020

@hems would locking the conversation solve your use case?

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.

@merlinpatt
Copy link

@merlinpatt merlinpatt commented 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
Copy link

@moorereason moorereason commented 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
Copy link

@Jonas-Sander Jonas-Sander commented 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 :/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet