改进 SECURITY.md 的建议

目前的 SECURITY.md 文件非常简短,仅列出了两个联系电子邮件地址。虽然这提供了一个基本的联系方式,但将其扩展可以显著改善负责披露过程,防止低质量报告,并节省维护者的时间。 我想建议将 SECURITY.md 扩展到涵盖几个重要方面。以下是团队可以考虑添加的一些具体想法: 1. **范围和合格版本:** 明确哪些分支或版本适合安全报告(例如,是否必须在 `master` 和/或 `dev` 分支或最新的稳定版本上重现漏洞才能被视为)。 2. **安全问题定义(威胁模型):** 定义在 Unicorn 的上下文中实际构成安全漏洞的内容。例如,明确提到: * Unicorn 内的内存安全问题,可能由客户代码触发(例如,目标架构的辅助函数中的越界访问) * TCG 前端/优化器/后端中的缺陷,可能导致主机内存损坏或沙箱逃逸。 * 由客户代码执行直接引发的主机进程崩溃(DoS)。 * 将其与客户级别的小幅度模拟不精确区分开来。 3. **通信方法和与 PyPI 的集成:** 由于 GitHub 安全建议(GHSA) / 私有漏洞报告目前已禁用此仓库,电子邮件是唯一的选择。有必要澄清是否需要 PGP 加密(但这可能是个问题,因为这可能要求维护者彼此共享私钥)。 * 或者,考虑启用 GitHub 的私有漏洞报告。由于官方 unicorn 包托管在 PyPI 上,利用 GHSA 将使团队能够协调安全通告,自动同步与 Python 包装建议数据库。这确保 Python 用户在安全补丁发布时立即收到 Dependabot 提醒。 作为之前曾为 `dev` 分支修复崩溃并积极对 Unicorn 进行漏洞扫描(包括在 `dev` 和 `pr2349-rebased` 分支上进行差分漏洞扫描)的人,我注意到对这些指南的强烈需求。有个清晰的 SECURITY.md 将帮助像我这样的人确切地知道如何对发现的问题进行分类(例如,区分公共错误报告/Pull Request 和私有安全披露)。 关于相关的一点,由于许多架构更新和错误修复正在单独的功能和开发分支中积极开发,明确哪个分支应被视为当前安全审计的主要目标将会非常有益。了解将主要更新合并到 master 分支的一般时间表或策略将大大帮助研究人员协调他们的努力,并避免报告可能已在开发中解决的问题。 请注意,上面的内容仅是建议。欢迎添加,…