Comments (77)
+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.
from github.
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.
from github.
There are other use cases than merely the credential leak, consider if the repository is working through a security vulnerability.
from github.
+1 It'd be helpful for the dev team to be able to discuss things in a non-public way.
from github.
I would like this capability so that reports of Code of Conduct violations could be made privately on a public repo.
from github.
+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.
from github.
+1 - vulnerabilities should be able to be disclosed responsibly in issues.
from github.
+1
from github.
+1
from github.
+1
from github.
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.)
from github.
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.
from github.
+1
from github.
+1
from github.
+1
from github.
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.
Does https://docs.github.com/en/code-security/security-advisories/about-github-security-advisories give you some of the things you might want?
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.
from github.
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.
Does https://docs.github.com/en/code-security/security-advisories/about-github-security-advisories give you some of the things you might want?
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.
from github.
FYI, GitLab supports this.
from github.
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.
from github.
People have pasted npm account details in github issues on more than one occasion.
π
from github.
oh god. no no no no,
from github.
+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)
from github.
This is such a MASSIVE issue and it's been open for two and a half years. Will GitHub pull their finger out and respond to this? Losing respect for this organisation. π
By not addressing this you are HELPING cyber crime and costing organisations!!
from github.
@github -- is this feature on your roadmap?
from github.
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".
from github.
I actually consider this so important that I would actually sign up for a priced plan just to get it.
from github.
Any updates here? gosh it's been so long!
from github.
+1
from github.
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.
-
from github.
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.
Does https://docs.github.com/en/code-security/security-advisories/about-github-security-advisories give you some of the things you might want?
from github.
$ npm install -g cipherhub
$ cipherhub -d <<<hEK3gIQAwxnd2cFB8b+yO/zak/4yHMVeTi4ohpPkv1zoBFpHDoSr8aFn1jjApctgHUxilqRk5gssf0AUsHVJa2MXZ9HB31/DorVqul3h/mAKRXwonvITEmusQ/hTcSmk3Pc12/mtSb7m23YE5vx2h5Ntc7sxw8Ar6fXfq1s2KxP5OqfaoxGytVQ7PfO5/iD1fvqQKtrk32pQgTt/5+eNqcNgtPGCrrg4Ohm9OTlwkYKNdbGDyZrpfmch6xiC5QlBws+OkAAQbPgFeGljBm8Wnh2zRpzJKgCaE0cJBkmQNlL3lD1bo62nLm/OLzn2uQVpNByIMMX8yzKwlZTO2oWu6Q==
from github.
+1
from github.
+1
from github.
+1
from github.
+1
from github.
π
from github.
In one of my repos I have something that looks like a private issue created by @Sadads (whose profile 404s for me). The issue as well 404s for me, but is there, has an ID, and can be referenced from another test issue, albeit reveals limited details (see the tooltip and the autocomplete in the screenshot below).
from github.
+1
from github.
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
from github.
We would like to switch form gitlab to github but private/confidential issues are one of the key missing features right now :/
from github.
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.
from github.
Some related GitHub Support Community topics, where people are asking similar questions:
- https://github.community/t/when-will-we-finally-get-confidential-issues-for-security-tickets/124703
- https://github.community/t/api-to-create-security-alert/14030
GitHub response to the ask on confidential issues:
Iβm afraid I donβt have a timeline for when that feature might be added, sorry!
We do keep an eye on isaacs/github, but you might like to submit a feature request through our official product feedback form to reinforce to our product team that having private issues is really important to you!
I also don't see anything on the roadmap: https://github.com/github/roadmap/projects/1
from github.
+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.
from github.
Bump
from github.
+1
from github.
+1
from github.
+1 π
from github.
π
from github.
π
from github.
+1
from github.
π
from github.
π
from github.
+1
from github.
+1
from github.
+1
from github.
+1
from github.
+1
from github.
1+
from github.
How do you prevent those credentials from being emailed as notifications when the issue is created?
from github.
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
from github.
The owner can just edit to hide that cat. Is that not sufficient?
from github.
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?
from github.
@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.
from github.
+1 for responsible disclosure.
from github.
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.
from github.
π Will this ever be considered?
from github.
@isaacs Query: do the guys and gals @github actually read this / do you inform them of issues mentioned here? Otherwise this list is nice, but fairly useless since most people probably didn't read you readme with the request to send an email to github support...
from github.
Yes I emailed GitHub with a link to this and got a response;
Thanks for the feedback. I'll pass along your request to the Security team.
Cheers,
GitHub Support
from github.
It turns out GitHub "thought" @Sadads was a spam bot. After contacting support, the Issue finally showed upβ¦
from github.
It may be helpful if I want to provide remote access to virtual machine for project maintainers to fix platform-specific bug
from github.
I want this too.
from github.
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.
from github.
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.
from github.
@hems would locking the conversation solve your use case?
from github.
@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...
from github.
@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.
from github.
Still actual!!
from github.
Related Issues (20)
- Auto-summary of markdown files is not indented anymore? HOT 1
- Github Arctic Code Vault Contributor HOT 2
- Sorting git code repository HOT 7
- Ease of switching between bulleted and numbered lists HOT 2
- Image as hyperlink doesn't work in GitHub's render of .ipynb file HOT 2
- Internal Server Error - Seems to have happened before
- Let's check this!! HOT 2
- "Files changed" not cleared when navigating to Code / Issues / Pull requests HOT 2
- Automatic Issue Linking not working HOT 5
- Web UI Deletion HOT 2
- Cannot remove accidentally assigned pull request reviewer HOT 2
- Visual studio icon in Code menu HOT 2
- Allow .age attachments to issues HOT 4
- Add threading for comments made directly on a Pull Request HOT 2
- A little UI bug on GitHub HOT 2
- Allow me to edit comments of blocked users as a repo owner just like I can already edit issues HOT 1
- Cannot change the base branch of a pull request to a particular branch HOT 1
- test HOT 1
- π£ [NOTICE] This repo is being deprecated HOT 3
- test issue HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from github.