From: Tom Hromatka Date: Wed, 19 Jan 2022 17:45:37 +0000 (-0700) Subject: SECURITY.md: Add security file X-Git-Tag: v2.0.1~4^2~2 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=43dc9ace7782edad09d2d2ae9dd753158ca70253;p=thirdparty%2Flibcgroup.git SECURITY.md: Add security file Add a SECURITY.md file that outlines the process for handling security-related vulnerabilities. Signed-off-by: Tom Hromatka Reviewed-by: Kamalesh Babulal (cherry picked from commit 47543c98f9a4d3c8e971951da6f25609aa3a868f) --- diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 00000000..54f91be9 --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,45 @@ +The libcgroup Security Vulnerability Handling Process +=============================================================================== +https://github.com/libcgroup/libcgroup + +This document describes the processes through which sensitive security relevant +bugs can be responsibly disclosed to the libcgroup project and how the project +maintainers should handle these reports. Just like the other libcgroup process +documents, this document should be treated as a guiding document and not a +hard, unyielding set of regulations; the bug reporters and project maintainers +are encouraged to work together to address the issues as best they can, in a +manner which works best for all parties involved. + +### Reporting Problems + +Problems with the libcgroup library that are not suitable for immediate public +disclosure should be emailed to the current libcgroup maintainers; see below. +We typically request at most a 90 day time period to address the issue before +it is made public, but we will make every effort to address the issue as +quickly as possible and shorten the disclosure window. + +* Dhaval Giani, dhaval.giani@gmail.com +* Tom Hromatka, tom.hromatka@oracle.com + +### Resolving Sensitive Security Issues + +Upon disclosure of a bug, the maintainers should work together to investigate +the problem and decide on a solution. In order to prevent an early disclosure +of the problem, those working on the solution should do so privately and +outside of the traditional libcgroup development practices. One possible +solution to this is to leverage the GitHub "Security" functionality to create a +private development fork that can be shared among the maintainers, and +optionally the reporter. A placeholder GitHub issue may be created, but +details should remain extremely limited until such time as the problem has been +fixed and responsibly disclosed. If a CVE, or other tag, has been assigned to +the problem, the GitHub issue title should include the vulnerability tag once +the problem has been disclosed. + +### Public Disclosure + +Whenever possible, responsible reporting and patching practices should be +followed, including notification to the linux-distros and oss-security mailing +lists. + +* https://oss-security.openwall.org/wiki/mailing-lists/distros +* https://oss-security.openwall.org/wiki/mailing-lists/oss-security