Confidential (private) issues on public repo
Feature request: allow confidential issues on public repositories. As reference, check [GitLab's confidential issues](https://docs.gitlab.com/ce/user/project/issues/confidential_issues.html). 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. This is the opposite of #639 but perhaps can be handled in the same work package as it will require similar constructs.
Posted by dllud on Dec 17, 2017, 5:11 PM
Tags
Related issues
- struct's lifetime requirements can be bypassed via covariant field assignment
- Proposal to Reorganize the Moderation Team and Review Moderation Policies
- Progressive FPS degradation appears to be related to dota2.com — blocking the domain prevents the performance loss
- proposal: container/...: generic collection types
- Better Custom Endpoint BYOK
- A concrete policy for backward compatibility until Godot 5.0
Raise real-world problems, find people facing the same issue, and discuss solutions.4,500 issues0 comments
github (Other)
struct's lifetime requirements can be bypassed via covariant field assignment
Proposal to Reorganize the Moderation Team and Review Moderation Policies
Progressive FPS degradation appears to be related to dota2.com — blocking the domain prevents the performance loss
proposal: container/...: generic collection types
Better Custom Endpoint BYOK
A concrete policy for backward compatibility until Godot 5.0
New MTP models not supported
Tracking: 429 / Capacity Issues
Confidential (private) issues on public repo
Feature request: allow confidential issues on public repositories. As reference, check [GitLab's confidential issues](https://docs.gitlab.com/ce/user/project/issues/confidential_issues.html). 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. This is the opposite of #639 but perhaps can be handled in the same work package as it will require similar constructs.
Comments (0)
No comments yet. Start the discussion.