@drakenclimber I'll throw up a quick outline for a MAINTAINER_PROCESS.md doc that we can discuss/edit, but I'm still trying to wrap up the v2.4.0 release right now, and I'll likely need a few days to tend to a few other unrelated and neglected issues :)

@pcmoore - No worries. Nice work on the v2.4 release by the way! Let me know how I can help.

Feel free to use me as a guinea pig as we get the process straightened out :)

Nice work on the v2.4 release by the way! Let me know how I can help.

Whatever testing you can do is helpful at this point. I feel pretty good about the quality of this release, but a lot of the tricky bits changed so it isn't unreasonable to imagine some corner case broke in some application. I'm hopeful we won't have to do a "brown bag" v2.4.1 release, but you never know.

Feel free to use me as a guinea pig as we get the process straightened out :)

Glad to hear you say that becasue you are the guinea pig ;)

@drakenclimber I'm reserving this comment for a draft of the MAINTAINER_PROCESS.md document (I figure I can keep editing it here based on feedback). Feel free to submit any ideas thoughts you have in this issue and I'll put together a PR for this once we get something close.

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 <[email protected]>

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 they 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 <[email protected])

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.

Ideally I think it would be nice to get an ACK from each maintainer on each patch/PR, but I'm not sure if that would be too much of a roadblock? My gut feeling is that libseccomp patches/PRs are low enough volume that this shouldn't be a major problem but I'm curious what you think

Agreed. I think striving for an ACK for each patch would be good, but we may want to leave the flexibility open to bypass that for really simple patches, or other extenuating circumstances (long vacations, etc.). Obviously bypassing the other ACKs should be the exception not the norm, though.

Regardless of the above, I think patches from any given maintainer needs to be ACK'd and committed by a different maintainer.

This would definitely be a good habit to get into. It should help avoid silly mistakes.

We also need to document how to handle merging PRs and patches, e.g. maintainer sign-off, doing it by hand and not using the GitHub tools, etc.

I would be interested in seeing the process you recommend. Is there a reason we should avoid the built-in github tools?

I think the key here is to list all of the maintainers in the appropriate section in the README.md and mention that the maintainers should work together to resolve the problem and follow the appropriate responsible disclosure processes. We should include links to the linux-distros and oss-security lists.

Yes, providing an easy and safe method for others to report issues is critical. I agree.

Agreed. I think striving for an ACK for each patch would be good, but we may want to leave the flexibility open to bypass that for really simple patches, or other extenuating circumstances (long vacations, etc.). Obviously bypassing the other ACKs should be the exception not the norm, though.

Good points, I agree.

We also need to document how to handle merging PRs and patches, e.g. maintainer sign-off, doing it by hand and not using the GitHub tools, etc.

I would be interested in seeing the process you recommend. Is there a reason we should avoid the built-in github tools?

I really like the idea that everyone who touches a patch, either by authoring it or committing it to the main repo, explicitly adds their sign-off to the file. I also really think that the maintainers should do a make check on their local system before pushing anything to the main repo. Merging PRs directly from within the GitHub interface doesn't really allow one to do either of those things.

I imagine if the PR volume ever increased dramatically we could reconsider this, but right now the volume is low enough that the additional manual steps really aren't significant in my opinion.

Opinions @drakenclimber?

I just looked into the Google Groups mailing list and it looks like I can't use your oracle.com account/address as a manager/moderator account, it must be a Google account. At this point I think it's up to you @drakenclimber; if you want manager/moderator access you'll need to subscribe with a Google account.

It's worth noting that I don't currently moderate the list, and I don't think it should be moderated. At present the only posts which aren't immediately sent to the list are things which Google thinks are SPAM.

It's also worth nothing that the traffic on the mailing list outside commit notifications is approaching zero, most of the interaction happens on GitHub now. While I think we should keep the mailing list around, please don't feel you need to be a manager/moderator of the list in order to "share the burden", there is no "burden" in this case.

I imagine if the PR volume ever increased dramatically we could reconsider this, but right now the volume is low enough that the additional manual steps really aren't significant in my opinion. Opinions @drakenclimber?

Agreed. I'm fine with a manual step at this stage of the project. In fact, that's exactly what I've been doing for a while now.

At this point I think it's up to you @drakenclimber; if you want manager/moderator access you'll need to subscribe with a Google account.

While I think we should keep the mailing list around, please don't feel you need to be a manager/moderator of the list in order to "share the burden", there is no "burden" in this case.

Makes sense. You're welcome to add my gmail address if you're cool with that; I don't really see a downside, but it could prove helpful later. tom dot hromatka at gmail.

I just noticed that under the "Security" tab for the project GitHub seems to handle the SECURITY.md file in a special way (see CONTRIBUTING.md as an example). We should consider using this file as part of this process.

The "Security" tab also allows you to create a private fork of the project so that you can work on patches in private; this could be a big win in that it allows us to better collaborate on security fixes without making the issue public before the fix is ready.

That's a really cool feature. Good find!

@drakenclimber I just updated the doc in the comment above, check it out and let me know what you think. We still need to cobble together a SECURITY.md doc, but that should be pretty quick (just a few sentences); I'll throw a draft together once you are happy with the main doc above.

@drakenclimber I just subscribed your gmail address to the Google group and gave you manager/moderator access, if it isn't working let me know.

I just subscribed your gmail address to the Google group and gave you manager/moderator access, if it isn't working let me know.

Looks like it's working. I was able to login and go into the settings for the mail list. Thanks!

I just updated the doc in the comment above, check it out and let me know what you think.

Looks really good to me.

@drakenclimber here is a quick draft of a SECURITY.md document, thoughts?

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, [email protected]
• Tom Hromatka, tom.[email protected]

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

in a manner which works best for them.

nitpick - I would be tempted to change this to in a manner which works best for all parties involved.

I think the security vulnerability doc looks really good. Nice work!

in a manner which works best for them.

nitpick - I would be tempted to change this to in a manner which works best for all parties involved.

I like that, updating the draft now.

I think we are in enough agreement that it is worth putting together a PR with the doc/process updates, I'll do that now and post a link back here.

PR link (also included in the GH history above): https://github.com/seccomp/libseccomp/pull/158

I think you're all set now @drakenclimber, if you notice anything awry let me know.