1
处理PR来解决公共回购中的安全漏洞的最佳实践是什么？
具有公共存储库的开源项目应如何最好地处理安全报告但尚未公开披露的安全漏洞的拉取请求（PR）？ 我参与了一个有数百位贡献者的开源项目。作为定期计划的每月发布的一部分，我们每年发布几次安全公告和漏洞。在发布修补程序版本之前，我们不会发布有关漏洞的信息。我们能够在项目管理系统（JIRA）中安全地管理安全问题。但是，在将安全漏洞提交给GitHub时，我们没有一个很好的流程来掩盖可修复安全漏洞的PR。我们担心人们会在发布这些修补程序之前找到这些修补程序，并创建零日漏洞利用。 我们已经考虑过使用私有存储库来派生主存储库，但是我们当前的大部分审查和质量检查工作流都在PR上进行。如果我们将工作流仅移交给安全团队的私人仓库，则可以将修补程序公开时的时间减少到生成压缩包并将其发布到sourceforge所需的时间，这将是一个很大的改进。我们还可能需要避免将PR合并到我们的公开Beta中。 在朝这个方向发展之前，我想知道在具有开放存储库的开源项目中处理预发行安全性漏洞修复补丁的最佳实践是什么？如果可以通过使用不同于GitHub的平台来更好地解决问题，那么我应该提到我们正在评估迁移到GitLab的过程。