From 933b096abe76a96cdbc6d17afcab64a1cc0c1752 Mon Sep 17 00:00:00 2001 From: Paul Moore Date: Wed, 31 Jul 2019 16:25:43 -0600 Subject: doc: new process docs and various updates A number of updates mainly focused on paving the way for multiple maintainers and making better use of the GitHub vulnerability reporting tools. Signed-off-by: Paul Moore Acked-by: Tom Hromatka (cherry picked from commit 4bec773fb401433bbfbbef111a49e1d2acbc4fcf) Signed-off-by: Tom Hromatka Acked-by: Paul Moore --- README.md | 2 +- SECURITY.md | 45 +++++++++++++++++++ doc/admin/MAINTAINER_PROCESS.md | 95 +++++++++++++++++++++++++++++++++++++++++ 3 files changed, 141 insertions(+), 1 deletion(-) create mode 100644 SECURITY.md create mode 100644 doc/admin/MAINTAINER_PROCESS.md diff --git a/README.md b/README.md index cf67e47..df77af0 100644 --- a/README.md +++ b/README.md @@ -110,4 +110,4 @@ these tools are installed by default. Problems with the libseccomp library can be reported using the GitHub issue tracking system or the mailing list. Those who wish to privately report -potential vulnerabilities can send mail to paul@paul-moore.com. +potential vulnerabilities should follow the directions in SECURITY.md. diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 0000000..3a173cc --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,45 @@ +The libseccomp Security Vulnerability Handling Process +=============================================================================== +https://github.com/seccomp/libseccomp + +This document document attempts to describe the processes through which +sensitive security relevant bugs can be responsibly disclosed to the libseccomp +project and how the project maintainers should handle these reports. Just like +the other libseccomp 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 libseccomp library that are not suitable for immediate public +disclosure should be emailed to the current libseccomp maintainers, the list is +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. + +* Paul Moore, paul@paul-moore.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 libseccomp 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 diff --git a/doc/admin/MAINTAINER_PROCESS.md b/doc/admin/MAINTAINER_PROCESS.md new file mode 100644 index 0000000..6ae61ba --- /dev/null +++ b/doc/admin/MAINTAINER_PROCESS.md @@ -0,0 +1,95 @@ +The libseccomp Maintainer Process +=============================================================================== +https://github.com/seccomp/libseccomp + +This document attempts to describe the processes that should be followed by the +various libseccomp maintainers. It is not intended as a hard requirement, but +rather as a guiding document intended to make it easier for multiple +co-maintainers to manage the libseccomp project. + +We recognize this document, like all other parts of the libseccomp project, is +not perfect. If changes need to be made, they should be made following the +guidelines described here. + +### Reviewing and Merging Patches + +In a perfect world each patch would be independently reviewed and ACK'd by each +maintainer, but we recognize that is not likely to be practical for each patch. +Under normal circumstances, each patch should be ACK'd by a simple majority of +maintainers (in the case of an even number of maintainers, N/2+1) before being +merged into the repository. Maintainers should ACK patches using a format +similar to the Linux Kernel, for example: + +``` +Acked-by: John Smith +``` + +The maintainer which merged the patch into the repository should add their +sign-off after ensuring that it is correct to do so (see the documentation on +submitting patches); if it is not correct for the maintainer to add their +sign-off, it is likely the patch should not be merged. The maintainer should +add their sign-off using the standard format at the end of the patch's +metadata, for example: + +``` +Signed-off-by: Jane Smith +``` + +The maintainers are encouraged to communicate with each other for many reasons, +one of which is to let the others when one is going to be unreachable for an +extended period of time. If a patch is being held due to a lack of ACKs and +the other maintainers are not responding after a reasonable period of time (for +example, a delay of over two weeks), as long as there are no outstanding NACKs +the patch can be merged without a simple majority. + +### Managing Sensitive Vulnerability Reports + +The libseccomp vulnerability reporting process is documented in the SECURITY.md +document. + +The maintainers should work together with the reporter to asses the validity +and seriousness of the reported vulnerability. 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 + +### Managing the GitHub Issue Tracker + +We use the GitHub issue tracker to track bugs, feature requests, and sometimes +unanswered questions. The conventions here are intended to help distinguish +between the different uses, and prioritize within those categories. + +Feature requests MUST have a "RFE:" prefix added to the issue name and use the +"enhancement" label. Bug reports MUST a "BUG:" prefix added to the issue name +and use the "bug" label. + +Issues SHOULD be prioritized using the "priority/high", "priority/medium", and +"priority/low" labels. The meaning should hopefully be obvious. + +Issues CAN be additionally labeled with the "pending/info", "pending/review", +and "pending/revision" labels to indicate that additional information is +needed, the issue/patch is pending review, and/or the patch requires changes. + +### Managing the GitHub Release Milestones + +There should be at least two GitHub milestones at any point in time: one for +the next major/minor release (for example, v2.5), and one for the next patch +release (for example, v2.4.2). As issues are entered into the system, they can +be added to the milestones at the discretion of the maintainers. + +### Managing the Public Mailing List + +The mailing list is currently hosted on Google Groups, and while it is possible +to participate in discussions without a Google account, a Google account is +required to moderate/administer the group. Those maintainers who do have a +Google account and wish to be added to the moderators list should be added, but +there is no requirement to do so. + +Despite the term "moderator" the list is currently unmoderated and should +remain the way. + +### New Project Releases + +The libseccomp release process is documented in the RELEASE_PROCESS.md +document. -- cgit v1.2.1