@drakenclimber我会为我们可以讨论/编辑的 MAINTAINER_PROCESS.md 文档提供一个快速大纲，但我现在仍在尝试完成 v2.4.0 版本，我可能需要几天时间倾向于其他一些不相关和被忽视的问题:)

@pcmoore - 不用担心。 顺便说一下，在 v2.4 版本上做得很好！ 让我知道我可以如何提供帮助。

当我们理顺这个过程时，请随意使用我作为豚鼠:)

顺便说一下，在 v2.4 版本上做得很好！ 让我知道我可以如何提供帮助。

在这一点上，您可以做的任何测试都是有帮助的。 我对这个版本的质量感觉很好，但是很多棘手的地方发生了变化，所以想象某些应用程序中的某些极端情况并非没有道理。 我希望我们不必发布“棕色包”v2.4.1 版本，但您永远不会知道。

当我们理顺这个过程时，请随意使用我作为豚鼠:)

很高兴听到你说因为你是豚鼠；）

@drakenclimber我将此评论保留为 MAINTAINER_PROCESS.md 文档的草稿（我想我可以根据反馈继续在这里编辑它）。 随意提交您在这个问题上的任何想法，一旦我们接近，我会为此整理一个 PR。

libseccomp 维护者进程

https://github.com/seccomp/libseccomp

本文档试图描述各种 libseccomp 维护者应该遵循的过程。 它并不是一个硬性要求，而是一个指导文档，旨在使多个共同维护者更容易管理 libseccomp 项目。

我们认识到该文档与 libseccomp 项目的所有其他部分一样并不完美。 如果需要进行更改，则应按照此处描述的指南进行更改。

查看和合并补丁

在一个完美的世界中，每个补丁都会由每个维护者独立审查和确认，但我们认识到这对于每个补丁来说都不可能实用。 在正常情况下，每个补丁在合并到存储库之前应该由简单的大多数维护者（在偶数维护者的情况下，N/2+1）确认。 维护者应该使用类似于 Linux 内核的格式来确认补丁，例如：

Acked-by: John Smith <[email protected]>

将补丁合并到存储库中的维护者应在确保这样做正确后添加他们的签名（请参阅提交补丁的文档）； 如果维护者添加他们的签名不正确，他们的补丁很可能不应该被合并。 维护者应该在补丁元数据的末尾使用标准格式添加他们的签名，例如：

Signed-off-by: Jane Smith <[email protected])

出于多种原因，我们鼓励维护者相互交流，其中之一是在某个人长时间无法访问时让其他人进行交流。 如果由于缺少 ACK 导致补丁被搁置，并且其他维护者在合理的时间段（例如，延迟超过两周）后没有响应，只要没有未完成的 NACK，就可以合并补丁没有简单多数。

管理敏感漏洞报告

libseccomp 漏洞报告过程记录在 SECURITY.md 文档中。

维护人员应与报告者一起评估报告漏洞的有效性和严重性。 只要有可能，就应该遵循负责任的报告和修补实践，包括通知 _linux-distros_ 和 _oss-security_ 邮件列表。

• https://oss-security.openwall.org/wiki/mailing-lists/distros

管理 GitHub 问题跟踪器

我们使用 GitHub 问题跟踪器来跟踪错误、功能请求和有时未回答的问题。 这里的约定旨在帮助区分不同的用途，并在这些类别中确定优先级。

功能请求必须在问题名称中添加“RFE：”前缀并使用“增强”标签。 错误报告必须在问题名称中添加“BUG：”前缀并使用“错误”标签。

应该使用“优先级/高”、“优先级/中”和“优先级/低”标签对问题进行优先级排序。 意思应该是显而易见的。

问题可以另外标有“待定/信息”、“待定/审查”和“待定/修订”标签，以指示需要附加信息、问题/补丁正在等待审查和/或补丁需要更改。

管理 GitHub 发布里程碑

在任何时间点都应该至少有两个 GitHub 里程碑：一个用于下一个主要/次要版本（例如，v2.5），一个用于下一个补丁版本（例如，v2.4.2）。 当问题进入系统时，维护人员可以自行决定将它们添加到里程碑中。

管理公共邮件列表

邮件列表目前托管在 Google Groups 上，虽然没有 Google 帐户也可以参与讨论，但需要一个 Google 帐户来管理/管理该组。 应该添加那些拥有 Google 帐户并希望添加到版主列表的维护者，但没有要求这样做。

尽管有“版主”一词，但该列表目前没有经过审核，应该保持不变。

新项目发布

libseccomp 发布过程记录在 RELEASE_PROCESS.md 文档中。

理想情况下，我认为在每个补丁/PR 上从每个维护者那里获得 ACK 会很好，但我不确定这是否会造成太大的障碍？ 我的直觉是 libseccomp 补丁/PR 的数量足够小，这应该不是主要问题，但我很好奇您的想法

同意。 我认为为每个补丁争取一个 ACK​​ 会很好，但我们可能希望保留灵活性以绕过非常简单的补丁或其他情有可原的情况（长假等）。 显然，绕过其他 ACK 应该是例外而不是常态。

不管上述情况如何，我认为来自任何给定维护者的补丁都需要由不同的维护者确认和提交。

这绝对是一个值得养成的好习惯。 它应该有助于避免愚蠢的错误。

我们还需要记录如何处理合并 PR 和补丁，例如维护者签字、手工完成而不使用 GitHub 工具等。

我很想看看你推荐的过程。 我们是否有理由避免使用内置的 github 工具？

我认为这里的关键是在 README.md 的适当部分列出所有维护者，并提到维护者应该共同努力解决问题并遵循适当的负责任的披露流程。 我们应该包括指向 linux-distros 和 oss-security 列表的链接。

是的，为他人报告问题提供一种简单且安全的方法至关重要。 我同意。

同意。 我认为为每个补丁争取一个 ACK​​ 会很好，但我们可能希望保留灵活性以绕过非常简单的补丁或其他情有可原的情况（长假等）。 显然，绕过其他 ACK 应该是例外而不是常态。

好点，我同意。

我们还需要记录如何处理合并 PR 和补丁，例如维护者签字、手工完成而不使用 GitHub 工具等。

我很想看看你推荐的过程。 我们是否有理由避免使用内置的 github 工具？

我真的很喜欢这样的想法，即每个接触补丁的人，无论是通过创作它还是将其提交到主存储库，都明确地将他们的签名添加到文件中。 我也真的认为维护者应该在将任何东西推送到主存储库之前在他们的本地系统上做一个make check 。 直接从 GitHub 界面内合并 PRs 并不能真正允许做这些事情中的任何一件。

我想如果 PR 数量急剧增加，我们可以重新考虑这一点，但现在数量足够低，以至于我认为额外的手动步骤并不重要。

意见@drakenclimber？

我刚刚查看了 Google Groups 邮件列表，看起来我不能将您的 oracle.com 帐户/地址用作经理/版主帐户，它必须是 Google 帐户。 在这一点上，我认为这取决于你@drakenclimber； 如果您想要管理员/版主访问权限，则需要使用 Google 帐户订阅。

值得注意的是，我目前不审核该列表，我认为也不应该审核它。 目前，唯一没有立即发送到列表的帖子是 Google 认为是垃圾邮件的内容。

提交通知之外的邮件列表上的流量接近零也是毫无价值的，现在大部分交互都发生在 GitHub 上。 虽然我认为我们应该保留邮件列表，但请不要觉得您需要成为列表的经理/版主才能“分担负担”，在这种情况下没有“负担”。

我想如果 PR 数量急剧增加，我们可以重新考虑这一点，但现在数量足够低，以至于我认为额外的手动步骤并不重要。 意见@drakenclimber？

同意。 在项目的这个阶段，我可以使用手动步骤。 事实上，这正是我一直在做的事情。

在这一点上，我认为这取决于你@drakenclimber； 如果您想要管理员/版主访问权限，则需要使用 Google 帐户订阅。

虽然我认为我们应该保留邮件列表，但请不要觉得您需要成为列表的经理/版主才能“分担负担”，在这种情况下没有“负担”。

说得通。 如果你觉得很酷，欢迎你添加我的 gmail 地址； 我并没有真正看到缺点，但它可能会在以后被证明是有帮助的。 gmail 的 tom dot hromatka。

我刚刚注意到在项目 GitHub 的“安全”选项卡下似乎以一种特殊的方式处理 SECURITY.md 文件（以 CONTRIBUTING.md 为例）。 我们应该考虑使用这个文件作为这个过程的一部分。

“安全”选项卡还允许您创建项目的私有分支，以便您可以私下处理补丁； 这可能是一个巨大的胜利，因为它使我们能够更好地协作进行安全修复，而无需在修复准备好之前将问题公开。

这是一个非常酷的功能。 好找！

@drakenclimber我刚刚更新了上面评论中的文档，请查看并告诉我您的想法。 我们仍然需要拼凑一个 SECURITY.md 文档，但这应该很快（只需几句话）； 一旦您对上面的主要文档感到满意，我就会将草稿放在一起。

@drakenclimber我刚刚将您的 gmail 地址订阅到了 Google 群组，并为您提供了经理/版主访问权限，如果它不起作用，请告诉我。

我刚刚将您的 Gmail 地址订阅到了 Google 群组，并为您提供了经理/版主访问权限，如果它不起作用，请告诉我。

看起来它正在工作。 我能够登录并进入邮件列表的设置。 谢谢！

我刚刚更新了上面评论中的文档，请查看并告诉我您的想法。

对我来说看起来真的很好。

@drakenclimber这里是 SECURITY.md 文件的快速草稿，有什么想法吗？

libseccomp 安全漏洞处理流程

https://github.com/seccomp/libseccomp

本文档试图描述可以负责任地向 libseccomp 项目披露敏感安全相关错误的过程，以及项目维护人员应如何处理这些报告。 就像其他 libseccomp 流程文档一样，本文档应被视为指导性文档，而不是一套硬性、不屈不挠的规定； 鼓励错误报告者和项目维护者共同努力，以对所有相关方最有效的方式尽其所能解决问题。

报告问题

不适合立即公开披露的 libseccomp 库问题应通过电子邮件发送给当前的 libseccomp 维护者，列表如下。 在问题公开之前，我们通常要求最多 90 天的时间来解决问题，但我们将尽一切努力尽快解决问题并缩短披露窗口。

• 保罗·摩尔， [email protected]
• 汤姆 Hromatka，汤姆。 [email protected]

解决敏感的安全问题

一旦发现错误，维护人员应共同调查问题并决定解决方案。 为了防止问题的早期披露，解决方案的工作人员应该在传统的 libseccomp 开发实践之外私下进行。 一种可能的解决方案是利用 GitHub 的“安全”功能创建一个私有的开发分支，可以在维护者和报告者之间共享。 可能会创建占位符 GitHub 问题，但在问题得到修复和负责任地披露之前，细节应保持极其有限。 如果 CVE 或其他标签已分配给问题，一旦问题被披露，GitHub 问题标题应包含漏洞标签。

公开披露

只要有可能，就应该遵循负责任的报告和修补实践，包括通知 linux-distros 和 oss-security 邮件列表。

• https://oss-security.openwall.org/wiki/mailing-lists/distros

以最适合他们的方式。

挑剔 - 我很想把它改成in a manner which works best for all parties involved.

我认为安全漏洞文档看起来非常好。 干得好！

以最适合他们的方式。

挑剔 - 我很想把它改成in a manner which works best for all parties involved.

我喜欢这样，现在更新草稿。

我认为我们一致认为值得将 PR 与文档/流程更新放在一起，我现在会这样做并在此处发布链接。

PR 链接（也包含在上面的 GH 历史记录中）： https :

我想你现在已经准备好了@drakenclimber ，如果你发现任何