GitHub 上 Go 项目（golang/go）仓库中第 82345 号议题的标题为代码安全（Code security），正文开头明确提出，应在构建代码的同时保护代码安全，把安全防护融入构建流程，让代码在整个构建过程中始终受到保护，实现边构建边守护代码安全的目标。

代码安全：在构建过程中保护你的代码。

讨论气氛严肃且带技术紧迫感：多数人认可被屏蔽CA已发生私钥彻底泄露，Go、Node、rustls/webpki、Electron等运行时同步封堵并应尽快升级；分歧主轴在于少数人质疑语言平台是否应自带根CA列表而非交给操作系统信任库，以及怀疑封堵背后存在国家安全信函（NSL）。反直觉焦点是证书透明度（CT）日志反过来拒绝记录这些CA签发的证书，导致野外伪造证书无处留痕，却仍能攻击不强制CT的客户端。

认为被屏蔽CA已私钥彻底泄露，且CT日志封锁让伪造证书更难被发现

• 有评论指出，CT日志实现突然更新以阻止记录这些CA签发的证书，这种反常操作基本等于承认CA私钥已完全失守；其目的虽然是防止日志被伪造证书刷屏，但也导致在野外发现的伪造证书再没有地方留痕。这些证书在强制CT的客户端里无法通过验证，却仍能攻击不强制CT的客户端。（认可度：高赞） > 证书透明度日志突然拒绝记录这些CA签发的证书，基本等于承认私钥已彻底失守，但也导致野外的伪造证书再没有地方留痕。（@agwa）

认为多运行时同步封堵证明事态严重，必须立刻升级

• 除Go之外，Node、rustls/webpki、Electron等证书校验方都已提交或合并了同样的封堵改动，说明这不是某一个语言平台的独有动作，而是生态级应急响应；评论者提醒大家一定要升级相关运行时或依赖，并期待OpenSSL尽快补丁。（认可度：高赞） > 除Go外，Node、rustls/webpki和Electron也都在做同样的封堵，事情非常严重，大家一定要升级。（@agwa）

质疑Go等语言平台自带根CA列表，信任应交给操作系统

• 有评论抱怨Go自己维护根证书列表，认为这明明是操作系统信任库的职责；Windows、macOS和多数Linux发行版本来就有系统级信任存储，像Java那样还要额外保持更新已经够麻烦，语言运行时不该再插一手。即便操作系统信任这些证书，Go程序也不会信任，这种“绕过系统”的做法被视作不寻常。（认可度：较多人） > 根证书信任明明是操作系统该管的事，Go却要自己带一份根CA列表，光是像Java那样保持更新就够烦了。（@mschuster91）

怀疑封堵背后存在国家安全信函等强制要求

• 由于Go即便面对操作系统已信任的证书仍选择不信任，有评论认为这种封堵极不寻常，猜测相关CA可能收到了国家安全信函（NSL）一类无法公开抗拒的强制命令。（认可度：少数人） > 连操作系统都信任的证书，用Go写的程序却偏偏不信任，这不正常到让我怀疑有人拿到了国家安全信函。（@direwolf20）

用玩笑调侃运行时把自己当成根CA

• 一条评论把编译器或运行时似乎自认为成了根证书颁发机构的情景，形容为“先生，这里是温迪快餐店”式的错位梗，用来表达社区对语言平台越权处理根信任的荒诞感。（认可度：少数人） > 编译器以为自己成了根证书颁发机构，简直像在说“先生，这里是温迪快餐店”。（@accountrequired）

有价值的补充

• 被屏蔽CA的证书列表来自公共证书颁发机构数据库（CCADB）资源，Mozilla的Bugzilla中也有相关报告；目前在证书透明度日志中查到的多是非恶意测试证书。（@mendym、@ericbarrett、@agwa）
• 一张测试证书里的DNS名称指向了疑似发现者的域名；发现者本人用curl手动指定解析访问了该域名，并把这次验证称为一次小型CTF挑战。（@q3k、@agwa）
• 有评论指出，证书格式上看似允许一张证书由多个CA共同签名，但现实中没有任何实现支持；证书颁发机构通常要求能修改某些字段后再签名，因此真正的多CA签名并不成立。（@wnoise）