-
Notifications
You must be signed in to change notification settings - Fork 13
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
Add a SECURITY.md for Cylc? #11
Comments
I think we should do this, but maybe wait on unbundling and packaging. |
Perhaps later we could also get one or two devs familiarised with the process to request CVE's, and start filling (maybe even retroactively) requests for when we find security issues in Cylc. I've never done it myself. But in the Jenkins and the ASF projects, there are teams that deal only with that, and give you the CVE RESERVED ID.
Right now there are no CVE's for Cylc, so users are not able to check which versions have which issues, and then choose a mitigation or update the version. Checked other software used for workflow in NWP, but they were also not listed in the Mitre DB. Article that covers more about challenges, issues, motivations, etc, for Open Source software & security: https://www.csoonline.com/article/3157377/application-development/open-source-software-security-challenges-persist.html |
While reading the docs for JupyterHub in Kubernetes, they mention the process used by JupyterHub/Jupyter for security issues, which is partially related to this issue: https://zero-to-jupyterhub.readthedocs.io/en/latest/security.html#reporting-a-security-issue |
This would be a good place to document that we are aware of the Jinja2 CVE that we can't take the fix for in cylc-7.8.x (the new Jinja2 version requires Python 3) but that it does not pose a risk in the Cylc context. |
@kinow - we can (I hope) close this with my new PRs to the main repo. Might be worth adding your comments above #11 (comment) to a new document in this (admin) repo though, for future reference? |
Yup, +1! We can add a link later to that document from other repositories like
Good idea, will do. In the future if we have a security bug (hoping it will be a veeeery far future :) we can have other discussion about posting it to the CVE public database. But we are quite busy and we made good progress with the neat new Once we are closer to Cylc 8 we might have more developer bandwidth and be able to support this more bureaucratic CVE security announcement process. |
Done in #26 |
See:
Not sure if needed.
The text was updated successfully, but these errors were encountered: