先说事件结论Mozilla 在发现一个 Firefox 扩展签名密钥的未加密副本出现在 GitHub 仓库后直接执行了吊销处理。签名密钥一旦落入公开仓库就不能再假设它安全这跟有没有被人下载过无关而是默认已经泄露。本文不打算复述一遍新闻标题而是从签名机制、事件技术路径、普通用户处置、扩展开发者应对、仓库密钥审计五个层面展开最后给出一套可以直接复用的排查流程。如果你正在使用 Firefox、给 Firefox 写过扩展、或者 GitHub 上任何一个仓库存放过证书、密钥、口令这类文件这篇文章值得看完。前面讲机制和影响后面给命令和工具可以直接照着操作。1. 事件核心速览项目说明事件类型密钥泄露与吊销处置涉及方Mozilla、Firefox 用户、扩展开发者、GitHub 仓库维护者核心问题Firefox 扩展签名密钥的未加密副本出现在公开 GitHub 仓库Mozilla 的动作吊销该签名密钥降低被恶意利用的风险风险等级高。签名密钥可用于伪造扩展签名进而影响扩展安装与更新链路普通用户影响需确认 Firefox 已更新、扩展安装与更新正常扩展开发者影响可能遇到签名失效、扩展被禁用或需要重新提交签名开发者通用教训任何密钥都不应进入代码仓库尤其是未加密副本从公开报道看这次事件的核心处置动作是吊销而不是删除文件后继续使用。这个选择本身就是安全行业的标准做法密钥一旦公开无论是否真的被滥用都必须立刻视为不可信然后启动轮换流程。2. 什么是 Firefox 签名密钥为什么被吊销值得关注2.1 签名密钥在 Firefox 生态里的作用Firefox 从较早期版本开始就要求扩展必须经过签名才能被安装到正式版本中。这个签名的目的有两个确认扩展确实来自某个开发者或发布渠道而不是第三方伪造。确认扩展打包文件xpi在发布后没有被篡改过。浏览器在安装扩展、检查扩展更新时会验证签名。如果签名无效Firefox 会拒绝安装或禁用该扩展。这套机制和 Windows 驱动签名、macOS 应用公证是同一个思路——用一条信任链保证用户拿到的代码是可信的。Mozilla 官方扩展商店 AMOaddons.mozilla.org负责对扩展进行签名。开发者提交扩展到 AMO 后AMO 会使用 Mozilla 的签名密钥对扩展包进行签名然后把签名后的包提供给用户下载。2.2 密钥泄露的风险模型如果攻击者拿到了 Firefox 扩展签名过程中使用的私钥他可以做这些事伪造一个签名有效的恶意扩展。对已经发布的合法扩展进行重打包植入恶意代码后重新签名。在某些场景下干扰扩展更新通道让用户接收到被篡改的版本。所以密钥泄露不是改个密码就行的问题而是整条信任链受到了威胁。Mozilla 选择吊销密钥本质上就是切断这条可能被污染的信任链强制所有依赖它的环节重新建立信任。2.3 密钥吊销意味着什么吊销不是删除一个文件那么简单。吊销意味着使用该密钥签发的所有扩展或组件需要重新用新密钥签名。Firefox 需要针对密钥轮换发布相应更新。扩展开发者可能需要重新提交或重新下载签名包。用户在密钥轮换完成前可能遇到扩展校验异常的情况。这里有一个容易混淆的点吊销针对的是密钥本身而不是特定版本的 Firefox。对你正在使用的扩展的影响取决于该扩展是否仍然依赖旧密钥以及 Firefox 更新后是否已经切换到新的校验逻辑。3. 事件技术分析未加密副本进入 GitHub 的典型风险3.1 密钥是怎么进入公开仓库的从公开信息看这次事件的直接原因是未加密副本进入 GitHub。这种泄露在开发者群体里非常常见一般有几种路径曾经是私有仓库后来被改成公开而敏感文件一直留在历史提交里。备份脚本或打包脚本把整个配置目录推送到仓库密钥文件被当成普通文件一起上传。为了在另一台机器上复现问题开发者把本机配置压缩后临时上传到仓库忘记删除。CI 构建过程把密钥明文输出到日志或产物目录随后被提交。无论是哪一种只要文件进入过一个公开仓库就不能再假设只有自己看过。Git 的历史记录、Fork、镜像、第三方抓取服务都可能保留副本。这也是为什么安全社区反复强调仓库里出现密钥处理方式不是删文件而是吊销并轮换。3.2 未加密为什么是关键未加密副本这个词很关键。如果密钥文件本身使用强密码加密攻击者拿到的是一份密文在没有口令的情况下无法直接使用。但未加密意味着拿到文件的人可以直接读取私钥内容、直接用于签名操作。所以不要抱着这个仓库访问量很小我很快就删掉了的侥幸心理。密钥一旦以明文形式出现在公网时间窗口内有多少人抓取过是根本没法统计的。吊销是唯一稳妥的处置路径。3.3 从发现到吊销的标准处置链路不管是 Mozilla 这次事件还是任何公司的密钥泄露事件标准处置链路基本是一致的确认密钥确实泄露并且泄露范围是公开的。评估泄露密钥的使用范围与权限边界。立即吊销密钥停止其继续使用的资格。生成新密钥替换所有依赖旧密钥的系统与服务。通知可能受影响的用户或开发者。复盘泄露路径补上流程和工具层面的漏洞。这次事件里Mozilla 没有选择先把仓库删掉再看情况而是直接吊销说明内部对密钥泄露的响应已经进入标准流程。这种处置方式本身也值得所有开发者学习。4. 普通 Firefox 用户应该做什么普通 Firefox 用户不需要做什么复杂操作但建议按下面的步骤快速自查一遍。4.1 确认 Firefox 版本与更新状态在 Firefox 地址栏输入about:about找到关于 Firefox入口或者直接在菜单里打开帮助 - 关于 Firefox。Firefox 会自动检查更新。如果发现有可用更新建议立即安装并重启浏览器。更新是拿到密钥轮换修复的最直接方式。Mozilla 在发现密钥问题后通常会通过常规版本更新把相关的修复和安全配置下发到用户端。4.2 检查已安装扩展是否正常在地址栏输入about:addons检查每个扩展的状态。如果你发现有扩展被自动禁用、提示无法验证签名或已损坏不要急着下载所谓的破解版或未签名版来绕过限制那是更危险的做法。正确的处理方式是确认该扩展是否仍在其官方页面提供更新版本。重新从 AMO 等官方渠道安装。如果重新安装后仍然提示签名错误等待扩展开发者重新签名并发布更新。4.3 如果 Firefox 无法自动更新的处理方式部分企业环境会通过组策略或管理配置锁定 Firefox 版本终端用户无法自行更新。这种情况下建议联系管理员确认组织内的 Firefox 是否已经应用最新的安全更新。个人用户如果更新失败优先检查磁盘空间、网络连接和杀毒软件拦截而不是从非官方渠道下载安装包。5. 对扩展开发者的影响与处理建议5.1 签名失效的表现如果你是 Firefox 扩展开发者这次密钥吊销可能对你的工作流产生影响。具体表现通常是本地开发时通过 web-ext 工具加载的临时扩展在自签名或使用开发签名后仍然提示无效。通过 AMO 提交的扩展在审核后返回签名失败。用户反馈扩展在更新后突然被禁用。遇到这些情况先去 AMO 开发者中心查看当前扩展的签名状态。如果 Mozilla 已经启用了新的签名密钥旧密钥签发的包就会失效你需要重新提交或重新下载签名文件。5.2 重新签名与版本发布建议重新签名后建议检查以下内容扩展的 manifest.json 中的版本号是否需要提升。本地存储的已签名 xpi 是否为最新生成。如果是自托管分发需要确认用户的更新源指向的是新签名文件。对于依赖 CI 自动打包发布的团队还需要检查构建流程里的签名步骤是否写死了旧密钥。密钥轮换后CI 环境中的密钥文件要同步替换否则下一次构建会直接失败或在静默状态下生成无效签名。5.3 测试通道与正式通道分开管理给扩展打开发签名和正式发布签名最好使用不同的密钥体系。这样即使开发密钥泄露也不会直接威胁到正式发布版本。Mozilla 的 AMO 体系本身也区分不同签名场景建议开发者仔细阅读其文档不要把测试通道的签名文件复用到正式发布。6. 从事件看密钥管理与 GitHub 仓库安全最佳实践这次事件给所有 GitHub 用户提了个醒仓库里的敏感文件管理比大多数开发者想象中更严格。下面的实践建议适用于任何团队建议直接收藏。6.1 密钥应该放在哪里密钥不应该放在项目代码目录里更不应该进入 Git 仓库。正确的存放位置包括专用密钥管理服务KMS、Vault、云厂商 Secrets Manager。本地密码管理器。硬件安全模块或安全 U 盘。环境变量或受保护的配置文件且不进入版本控制。如果你的项目确实需要把密钥写入配置文件一定要确保配置文件被 .gitignore 排除并且只允许在部署阶段由 CI 或运维平台注入。6.2 加密存储与访问控制如果密钥必须以文件形式存在至少要做到文件本身加密存储。访问权限按最小权限原则分配。目录和文件的系统权限严格限制。定期审计谁访问过这些文件。不要把仓库是私有的当作安全措施。私有仓库也可能被误改公开也可能因为账号泄露、协作库被外部访问而暴露。真正安全的做法是密钥根本不进入仓库。6.3 git 历史中的密钥泄漏问题很多密钥泄露不是发生在最新代码里而是隐藏在旧的 git 提交历史中。即使你删除了当前文件历史记录里的副本依然存在。这意味着清理工作不是删一次文件那么简单。如果是 GitHub 仓库需要联系 GitHub 支持处理历史记录如果是自建 Git 服务需要对历史进行重写并强制推送。但更稳妥的做法仍然是吊销并轮换密钥而不是只清理历史。6.4 仓库可见性审计建议定期检查组织下的所有仓库确认每个仓库是否真的需要公开。可以用 GitHub CLI 快速列出仓库的可见性# 列出当前账号下所有仓库及其可见性 gh repo list --json name,visibility # 查看某个仓库详情 gh repo view owner/repo --json name,visibility,url针对已经公开的仓库重点检查这几个位置README 或文档中的示例配置是否包含真实密钥占位。测试用例里是否有硬编码密钥。历史提交中是否存在配置文件。CI 日志和发布产物是否包含敏感信息。6.5 密钥轮换机制不要等密钥泄露了才想到轮换。合理的做法是所有密钥都设置定期轮换周期并且有自动化的轮换流程。密钥过期时间、轮换责任人、轮换后的验证步骤都应该写清楚。这样一旦发生泄露你只需要提前执行已有的轮换流程而不是临时想办法。7. 如何用工具审计仓库中是否存在泄漏密钥与其担心密钥是否已经泄露不如直接在本地把仓库扫一遍。下面介绍三个常用工具覆盖提交前拦截、历史扫描、实时扫描三个环节。7.1 gitleaks全量扫描仓库历史gitleaks 可以扫描整个 git 历史找出所有提交中出现的密钥模式。安装后在仓库目录执行gitleaks detect --source . --report-path gitleaks-report.json --report-format json扫描结果会输出到 gitleaks-report.json里面包含命中的文件路径、提交哈希和密钥类型。也可以在 CI 里直接跑gitleaks detect --source . --verbose --redact--redact参数会在输出中遮住密钥内容避免扫描结果本身又成为泄露源。7.2 git-secrets提交前拦截git-secrets 是一个提交前钩子工具可以在 git commit 之前检查暂存内容里是否包含密钥。安装方式git secrets --install git secrets --register-aws--register-aws会注册 AWS 密钥格式的检测规则。如果要检测自定义后缀比如 PEM 私钥可以手动追加规则git secrets --add -----BEGIN (RSA|EC|OPENSSH|PRIVATE) KEY-----安装后每次提交都会自动检查。执行手动扫描可以用git secrets --scan7.3 用 git 自带命令搜索私钥特征如果没有安装任何工具也可以用 git 命令直接在历史里搜索私钥特征# 在全部历史中搜索私钥头部 git rev-list --all | xargs git grep -l BEGIN PRIVATE KEY 2/dev/null# 在全部历史中搜索常见密钥文件名 git rev-list --all | xargs git grep -l id_rsa\|\.pem\|\.pfx\|keystore 2/dev/null注意这种搜索只能作为辅助手段因为密钥可能有多种编码形式。而且搜索结果命中的文件不代表一定泄露还需要人工确认。7.4 GitHub 自带 Secret ScanningGitHub 原生提供 Secret Scanning 和 Push Protection 功能。Secret Scanning 会扫描仓库历史中的已知厂商密钥格式一旦发现会向仓库管理员发送告警。Push Protection 会在开发者试图把密钥推送到公开仓库时直接拦截推送。建议所有团队都开启这两个功能并把 Mozilla 这次事件作为案例写进团队的安全培训文档里。8. 常见问题排查与后续观察问题现象可能原因排查方式处理建议Firefox 提示扩展无法验证签名扩展签名密钥已轮换旧签名失效查看 about:addons 中的错误提示从 AMO 重新安装最新版或等待开发者更新Firefox 无法检查更新网络受限或更新服务被拦截查看关于 Firefox页面中的更新状态检查网络与代理设置必要时手动下载安装包扩展被停用但重新安装仍然报错本地缓存了旧的签名包清除浏览数据或删除扩展后重装确认扩展官方页面已发布重新签名的版本git 仓库历史中存在密钥文件早期误提交使用 gitleaks 确认泄露范围优先吊销并轮换密钥不要只依赖删除历史第三方工具扫描出大量密钥告警测试配置文件或示例代码误报逐条确认是否真实密钥对真实密钥立即轮换伪密钥可加入白名单Secret Scanning 告警未被处理仓库管理员未配置通知检查 GitHub Security 页面建立告警处理 SLA明确责任人如果事件后续有新的官方公告建议关注 Mozilla 安全博客和 AMO 开发者中心的公告而不是依赖社交媒体上的二手信息。对于一些不活跃维护的旧扩展如果开发者没有在合理时间内完成重新签名可以考虑寻找替代扩展避免一直使用签名失效的版本。9. 总结与建议这次 Mozilla 吊销 Firefox 签名密钥的事件真正值得关注的不是某一个扩展能不能用而是密钥管理这条线被完整地暴露了一次。普通用户最应该验证的是Firefox 是否已经更新、扩展是否都能正常安装和更新。扩展开发者最应该验证的是自己的 CI 流程、签名配置是否依赖了可能已经被轮换的旧密钥。GitHub 仓库维护者最应该验证的是自己的仓库历史里有没有私钥、证书、口令这类文件不要等到 Secret Scanning 告警或者更糟的泄露事件发生后再被迫做一次紧急处置。这次事件最容易踩的坑是以为删掉文件就没事了。密钥一旦进入公开仓库唯一正确的路径是立即吊销、马上轮换。把这条原则沉淀到团队流程里比任何一次单独的清理都更有价值。接下来值得做的事很简单打开终端在你有权限的仓库上跑一遍 gitleaks看看扫描结果。如果没有任何命中说明你的仓库卫生状况不错如果有命中正好借这次事件把轮换流程走一遍。
