GitHub给仓库安全公告加了加密评论，报告者看不到

A5站长网10月3日消息，GitHub给仓库安全公告加了一项能力：维护者可以发布加密评论。这类评论只对拥有仓库写入权限的人可见，报告者以及其他没有写入权限的受邀协作者既看不到内容，也不会收到相关通知。有了这个入口，团队在安全公告里讨论疑似滥用、调查细节或协调记录时，不必再把内容搬到别的地方。

这个需求来自安全公告的使用方式。过去公告上的所有评论对全体协作者可见，包括提交报告的人。维护者想私下核对某个漏洞的可信度，或者讨论是否涉及协同攻击，只能转到邮件、私聊或另一个追踪系统里，结果就是这些讨论记录从公告的时间线里丢失了。等半年后回头复查同一个漏洞，最关键的那段判断依据已经找不到。

操作上是在发布评论前勾选一个选项，说明这条只对维护者可见。加密评论在公告时间线里会有明确标记，不会和普通评论混在一起。可见范围跟仓库当前的权限绑定：谁在这一刻拥有写入权限，谁就能读；一旦某人失去写入权限，他已经读过的加密评论也不再可见。对有多人协作的仓库来说，这条规则比一次性的名单更贴近实际。

审计方面做了一处补充。加密评论的查看行为会被记录进审计日志，也就是说，读这份内容这件事本身留下了痕迹。这条设计说明GitHub在思考的问题不只是“能不能藏”，还有“藏起来的内容该由谁负责”。对需要满足合规要求的团队，可追溯的读取记录往往和权限控制一样重要。

有一些限制需要提前知道。评论发布之后不能在加密与普通之间切换，选错了只能重发；加密评论支持GraphQL接口，但不会通过REST接口返回，依赖REST拉取公告评论的工具需要改成走GraphQL，否则会漏数据。可用范围是启用了私有漏洞报告的公开仓库，GitHub Free、Pro、Team和Enterprise Cloud这几个版本都能用。

把这条更新和同一周GitHub放出的另外几项改动连起来看，方向是一致的。10月1日刚给私有漏洞报告加了提交速率限制和结构化表单，更早一点还调整了npm可信发布的分发标签权限。这些改动共同指向一件事：开源维护者手上的安全流程正在从“都放在明面上等社区互助”，往“允许有内部判断空间，但每一步留痕”的方向挪。对维护者来说，这意味着工具变好用了，同时也意味着责任边界更清楚。