Closed jrn closed 7 months ago
Thanks for the heads up, looks like we missed this when migrating from Bugzilla.
According to [1] we can choose to either report security issues via confidential issues (GitLab) or private security advisories (GitHub).
AFAIR for tracking past security issues we used confidential GitLab issues, they came in via the Eclipse security team [2]. This worked well for me hence I'd tend to stick to this path. This is also the path described on the general security reporting page of the Eclipse Foundation [3].
I have no experience using GitHub security advisories. Maybe you have ? What's your preference ?
[1] https://www.eclipse.org/projects/handbook/#project-setup-for-vulnerability-reporting [2] https://www.eclipse.org/security/team/ [3] https://www.eclipse.org/security/
@mrybczyn what's your recommendation from the Eclipse security team ?
Can't we just remove our own SECURITY.md file in the repo and have the foundation's global one be used then by default?
AFAIR I was asked to add the SECURITY.md by EMO
AFAIR for tracking past security issues we used confidential GitLab issues, they came in via the Eclipse security team [2]. This worked well for me hence I'd tend to stick to this path.
I agree, this is a good path.
I have no experience using GitHub security advisories. Maybe you have ?
They're good for getting a CVE identifier and advertising it, but I didn't find them more useful than other tools for handling the flow of fixing an issue.
I pushed an update of SECURITY.md https://review.gerrithub.io/c/eclipse-jgit/jgit/+/1177352 using the text from https://www.eclipse.org/security/.
submitted update of SECURITY.md
Bug description
https://github.com/eclipse-jgit/jgit/security/policy states:
What is the github issues equivalent that we should be following?
Actual behavior
Instructions refer to the previous (bugzilla) bug tracker.
Expected behavior
Instructions refer to the current bug tracker.