Skip to content

Commit e214ef1

Browse files
pcmoorepcmoore
committed
docs: add admin docs as well as a local copy of SECURITY.md
This are based on the core libseccomp docs. Acked-by: Tom Hromatka <[email protected]> Signed-off-by: Paul Moore <[email protected]>
1 parent 2a71848 commit e214ef1

File tree

3 files changed

+154
-2
lines changed

3 files changed

+154
-2
lines changed

‎SECURITY.md‎

Lines changed: 46 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,47 @@
1-
## The libseccomp-golang Security Vulnerability Handling Process
1+
The libseccomp-golang Security Vulnerability Handling Process
2+
===============================================================================
3+
https://github.com/seccomp/libseccomp-golang
24

3-
The libseccomp-golang project follows the [libseccomp Security Vulnerability Handling Process](https://github.com/seccomp/libseccomp/blob/main/SECURITY.md).
5+
This document document attempts to describe the processes through which
6+
sensitive security relevant bugs can be responsibly disclosed to the
7+
libseccomp-golang project and how the project maintainers should handle these
8+
reports. Just like the other libseccomp-golang process documents, this
9+
document should be treated as a guiding document and not a hard, unyielding set
10+
of regulations; the bug reporters and project maintainers are encouraged to
11+
work together to address the issues as best they can, in a manner which works
12+
best for all parties involved.
13+
14+
### Reporting Problems
15+
16+
Problems with the libseccomp-golang library that are not suitable for immediate
17+
public disclosure should be emailed to the current libseccomp-golang
18+
maintainers, the list is below. We typically request at most a 90 day time
19+
period to address the issue before it is made public, but we will make every
20+
effort to address the issue as quickly as possible and shorten the disclosure
21+
window.
22+
23+
* Paul Moore, [email protected]
24+
* Tom Hromatka, [email protected]
25+
26+
### Resolving Sensitive Security Issues
27+
28+
Upon disclosure of a bug, the maintainers should work together to investigate
29+
the problem and decide on a solution. In order to prevent an early disclosure
30+
of the problem, those working on the solution should do so privately and
31+
outside of the traditional libseccomp-golang development practices. One
32+
possible solution to this is to leverage the GitHub "Security" functionality to
33+
create a private development fork that can be shared among the maintainers, and
34+
optionally the reporter. A placeholder GitHub issue may be created, but
35+
details should remain extremely limited until such time as the problem has been
36+
fixed and responsibly disclosed. If a CVE, or other tag, has been assigned to
37+
the problem, the GitHub issue title should include the vulnerability tag once
38+
the problem has been disclosed.
39+
40+
### Public Disclosure
41+
42+
Whenever possible, responsible reporting and patching practices should be
43+
followed, including notification to the linux-distros and oss-security mailing
44+
lists.
45+
46+
* https://oss-security.openwall.org/wiki/mailing-lists/distros
47+
* https://oss-security.openwall.org/wiki/mailing-lists/oss-security

‎doc/admin/MAINTAINER_PROCESS.md‎

Lines changed: 98 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,98 @@
1+
The libseccomp-golang Maintainer Process
2+
===============================================================================
3+
https://github.com/seccomp/libseccomp-golang
4+
5+
This document attempts to describe the processes that should be followed by the
6+
various libseccomp-golang maintainers. It is not intended as a hard
7+
requirement, but rather as a guiding document intended to make it easier for
8+
multiple co-maintainers to manage the libseccomp-golang project.
9+
10+
We recognize this document, like all other parts of the libseccomp-golang
11+
project, is not perfect. If changes need to be made, they should be made
12+
following the guidelines described here.
13+
14+
### Reviewing and Merging Patches
15+
16+
In a perfect world each patch would be independently reviewed and ACK'd by each
17+
maintainer, but we recognize that is not likely to be practical for each patch.
18+
Under normal circumstances, each patch should be ACK'd by a simple majority of
19+
maintainers (in the case of an even number of maintainers, N/2+1) before being
20+
merged into the repository. Maintainers should ACK patches using a format
21+
similar to the Linux Kernel, for example:
22+
23+
```
24+
Acked-by: John Smith <[email protected]>
25+
```
26+
27+
The maintainer which merged the patch into the repository should add their
28+
sign-off after ensuring that it is correct to do so (see the documentation on
29+
submitting patches); if it is not correct for the maintainer to add their
30+
sign-off, it is likely the patch should not be merged. The maintainer should
31+
add their sign-off using the standard format at the end of the patch's
32+
metadata, for example:
33+
34+
```
35+
Signed-off-by: Jane Smith <[email protected]>
36+
```
37+
38+
The maintainers are encouraged to communicate with each other for many reasons,
39+
one of which is to let the others when one is going to be unreachable for an
40+
extended period of time. If a patch is being held due to a lack of ACKs and
41+
the other maintainers are not responding after a reasonable period of time (for
42+
example, a delay of over two weeks), as long as there are no outstanding NACKs
43+
the patch can be merged without a simple majority.
44+
45+
### Managing Sensitive Vulnerability Reports
46+
47+
The libseccomp-golang vulnerability reporting process is documented in the
48+
SECURITY.md document.
49+
50+
The maintainers should work together with the reporter to asses the validity
51+
and seriousness of the reported vulnerability.
52+
53+
### Managing the GitHub Issue Tracker
54+
55+
We use the GitHub issue tracker to track bugs, feature requests, and sometimes
56+
unanswered questions. The conventions here are intended to help distinguish
57+
between the different uses, and prioritize within those categories.
58+
59+
Feature requests MUST have a "RFE:" prefix added to the issue name and use the
60+
"enhancement" label. Bug reports MUST a "BUG:" prefix added to the issue name
61+
and use the "bug" label.
62+
63+
Issues SHOULD be prioritized using the "priority/high", "priority/medium", and
64+
"priority/low" labels. The meaning should hopefully be obvious.
65+
66+
Issues CAN be additionally labeled with the "pending/info", "pending/review",
67+
and "pending/revision" labels to indicate that additional information is
68+
needed, the issue/patch is pending review, and/or the patch requires changes.
69+
70+
### Managing the GitHub Release Milestones
71+
72+
There should be at least two GitHub milestones at any point in time: one for
73+
the next major/minor release, and one for the next patch release. As issues
74+
are entered into the system, they can be added to the milestones at the
75+
discretion of the maintainers.
76+
77+
### Handling Inappropriate Community Behavior
78+
79+
The libseccomp-golang project community is relatively small, and almost always
80+
respectful and considerate. However, there have been some limited cases of
81+
inappropriate behavior and it is the responsibility of the maintainers to deal
82+
with it accordingly.
83+
84+
As mentioned above, the maintainers are encouraged to communicate with each
85+
other, and this communication is very important in this case. When
86+
inappropriate behavior is identified in the project (e.g. mailing list, GitHub,
87+
etc.) the maintainers should talk with each other as well as the responsible
88+
individual to try and correct the behavior. If the individual continues to act
89+
inappropriately the maintainers can block the individual from the project using
90+
whatever means are available. This should only be done as a last resort, and
91+
with the agreement of all the maintainers. In cases where a quick response is
92+
necessary, a maintainer can unilaterally block an individual, but the block
93+
should be reviewed by all the other maintainers soon afterwards.
94+
95+
### New Project Releases
96+
97+
The libseccomp-golang release process is documented in the RELEASE_PROCESS.md
98+
document.

‎doc/admin/RELEASE_PROCESS.md‎

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,10 @@
1+
The libseccomp-golang Release Process
2+
===============================================================================
3+
https://github.com/seccomp/libseccomp-golang
4+
5+
This is the process that should be followed when creating a new
6+
libseccomp-golang release.
7+
8+
#### TODO: create a release process using libseccomp as a reference
9+
10+
* https://github.com/seccomp/libseccomp/blob/main/doc/admin/RELEASE_PROCESS.md

0 commit comments

Comments
 (0)