You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently and on most git hosting providers, issues are always public. While this is of course desired default behaviour, I propose to add an option for internal or private issues (and may be even pull / merge requests) for the following reasons:
Security Reports: There is no standardized way to send security reports to developers or maintainers of the software Usually, there's a hint that they should be reported via E-Mail. But this way, they fall out of the default bug tracking and must be discussed elsewhere.
Internal discussion: Also especially useful for handling vulnerabilities, discussing fixes and preparing pull requests that are only visible to the public once merged, it might also be a good idea to allow some discussion between maintainers privately.
Sensitive information: Sometimes, debugging an issue requires disclosing logs with sensitive information or providing access to test systems etc. They are usually sent via external tools e.g. email. It would be a cool feature to keep this in the issue tracker but allow only for limited access to the maintainers and the reporter.
How this might get implemented
Only my idea of how this could be handled: Upon issue creation, there's a switch to make it private (it could also be called "sensitive" or "allow only maintainers to access this report"). This way, a user could report a security issue and make sure only the maintainers receive the report. It's then hidden and only visible to members of the repo. (Fine-tuning this would of course also be an option as to toggle between the core maintainers and a broader circle of devs or something like this).
It should be possible to add members manually, maybe because they might be useful for this particular issue.
Controlling access could be made via a dedicated menu, but it might also be an idea to keep it simple: All members with certain access to the repo can see private issues and adding people is as simple as mentioning them. The latter one might of course introduce accidental disclosure of information when not being careful, this needs to be discussed further.
I think, such a feature would facilitate software development a lot and make sure that everything can be tracked within one platform instead of relying on external communication. And it would finally allow pull / merge requests to be discussed openly for security vulnerabilities. Often, they just contain mock information to prevent anyone from seeing this until a release etc.
Thank you for considering this.
The text was updated successfully, but these errors were encountered:
Feature Request
Description
Currently and on most git hosting providers, issues are always public. While this is of course desired default behaviour, I propose to add an option for internal or private issues (and may be even pull / merge requests) for the following reasons:
How this might get implemented
Only my idea of how this could be handled: Upon issue creation, there's a switch to make it private (it could also be called "sensitive" or "allow only maintainers to access this report"). This way, a user could report a security issue and make sure only the maintainers receive the report. It's then hidden and only visible to members of the repo. (Fine-tuning this would of course also be an option as to toggle between the core maintainers and a broader circle of devs or something like this).
It should be possible to add members manually, maybe because they might be useful for this particular issue.
Controlling access could be made via a dedicated menu, but it might also be an idea to keep it simple: All members with certain access to the repo can see private issues and adding people is as simple as mentioning them. The latter one might of course introduce accidental disclosure of information when not being careful, this needs to be discussed further.
I think, such a feature would facilitate software development a lot and make sure that everything can be tracked within one platform instead of relying on external communication. And it would finally allow pull / merge requests to be discussed openly for security vulnerabilities. Often, they just contain mock information to prevent anyone from seeing this until a release etc.
Thank you for considering this.
The text was updated successfully, but these errors were encountered: