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 <paul@paul-moore.com>
Acked-by: Tom Hromatka <tom.hromatka@oracle.com>
(cherry picked from commit 4bec773fb401433bbfbbef111a49e1d2acbc4fcf)
Signed-off-by: Tom Hromatka <tom.hromatka@oracle.com>
Acked-by: Paul Moore <paul@paul-moore.com>

3 files changed, 141 insertions, 1 deletions

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 <john.smith@email.org>
+```
+
+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 <jane.smith@email.org>
+```
+
+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.