一句话看懂：GitHub CLI（gh）在 Linux 上通过 APT/RPM 仓库分发时使用的 PGP 签名密钥将于 2026 年 9 月 5 日过期。如果你曾在今年 4 月 8 日前安装过官方仓库包且未更新配置，需要在到期前手动信任替换密钥，否则后续可能无法正常获取更新。
事件核心：发生了什么
GitHub 官方 Changelog 发布通知，用于签署 GitHub CLI Linux 包仓库的 PGP 密钥将在 2026 年 9 月 5 日（星期六）到期。GitHub 已于今年 4 月发布了一个同时包含当前密钥和替换密钥的 keyring。自该日期之后的首个版本发布起，APT 和 RPM 仓库的元数据以及新发布的 RPM 包将仅使用新密钥进行签名。
关键受影响的用户群是：在 2026 年 4 月 8 日之前从官方 APT 或 RPM 仓库安装 gh，且此后没有更新过相关安装配置的用户。GitHub 提醒这批用户需要在 9 月 5 日前按照完整公告中的指引手动更新系统信任的密钥。不确定自己安装时间，或是使用自定义镜像、自动化安装脚本的用户，也应主动核验系统是否信任新密钥。
为什么重要
这不是一次软件功能更新，而是一次软件供应链安全基础设施的例行更换。对开发者和运维团队来说，Linux 包管理器的签名密钥是验证软件包完整性和来源真实性的重要防线。密钥过期后若不及时处理，轻则导致 gh 无法正常拉取更新，重则可能因为包管理器报错而阻塞 CI/CD 流程中的自动化安装步骤。
GitHub 选择提前五个月发布双密钥 keyring，并且只对 RPM 元数据和新包强制切换（DEB 仓库仍沿用已有模式），一定程度上降低了迁移阵痛。但这依然提醒行业：即便像 GitHub CLI 这样受众极广的开源工具，在密钥轮换时也需要用户主动配合，而这种“静默过期”对长时间不维护的自动化环境尤其不友好。对于使用 Linux 服务器做 AI 训练或推理部署的团队，如果供应链脚本中写死了 gh 的安装步骤，这一点值得立刻检查。
对用户/开发者/创作者的影响
影响面主要限定在 Linux 平台上的直接安装方式。使用 Windows、macOS，通过 Homebrew、Conda 安装，或直接下载 GitHub Releases 中的 .deb 文件或独立归档二进制的用户，不受此次密钥更换影响。从源码编译的用户也不受波及。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
受影响最典型的场景是：Dockerfile 或云服务器初始化脚本里使用官方 APT/RPM 仓库安装 gh，且安装时间早于 2026 年 4 月 8 日。这类环境通常是无人值守的，很容易忽略此次密钥轮换。建议开发者在 9 月 5 日之前手动执行一次公告中提供的密钥更新命令，或者直接重新运行官方安装脚本，以确保系统信任的是替换后的新密钥。对于长期未更新的自建仓库镜像，也需要同步更新密钥文件。
值得关注的后续
目前公开信息显示，GitHub 未透露本次密钥到期后是否会缩短下一轮密钥的有效期。后续值得观察三点：第一，9 月 5 日后的首个 gh 发布是否会出现大量用户因未更新密钥而导致的安装报错反馈；第二，GitHub 是否会为自动化环境提供更平滑的密钥轮换机制，比如支持短期密钥或引入透明的过期预警；第三，其他依赖 GitHub 官方仓库分发的 Linux 工具（如 GitHub Actions Runner）是否会在近期跟进类似的密钥轮换流程。建议仍在用旧密钥签发的仓库源的用户，在日历上标记 9 月 5 日，提前处理好密钥信任问题。
