GitHub CLI 的 Linux 签名密钥到期后怎么更新

如果你在 Debian、Ubuntu、Fedora 或其他 Linux 发行版上通过 GitHub CLI 官方 APT/RPM 仓库安装了 gh，先更新本地 keyring 或仓库配置，再执行包管理器更新。GitHub CLI 的旧签名密钥已在 2026 年 9 月 5 日到期；新 keyring 已包含替换密钥。通过 Homebrew、Conda、源码、GitHub Releases 二进制包安装的用户不属于这次轮换范围。

最稳妥的处理顺序是：先确认安装渠道，再确认本地是否已有新指纹；只有旧 keyring 的官方 APT/RPM 用户需要刷新信任配置，随后再运行 apt、dnf、yum 或 zypper 更新。

先确认安装渠道和本机信任链

这不是一次所有用户都要做的 gh 升级。GitHub 公告把影响面限定在 Linux 官方 APT 和 RPM 仓库：如果是在 2026 年 4 月 8 日新 keyring 发布前按官方文档安装，且之后没有重新执行安装配置，就应当检查。已经使用新安装流程的用户，本地 keyring 通常已经同时包含旧、新两把公钥。

Debian/Ubuntu 可以直接查看 keyring。若推荐路径不存在，再检查旧路径或 APT 源文件中的 signed-by 值：

# 查看推荐路径中的公钥，确认是否有两条 pub 记录
gpg --show-keys /etc/apt/keyrings/githubcli-archive-keyring.gpg

# 文件不在推荐路径时，尝试旧路径或查看 APT 源配置
gpg --show-keys /usr/share/keyrings/githubcli-archive-keyring.gpg
cat /etc/apt/sources.list.d/github-cli.list

如果输出同时出现旧指纹和 7F38BBB59D064DBCB3D84D725612B36462313325，就不必重复导入。RPM 系统则可以查看已导入的 GitHub CLI 公钥；只有一个旧条目时才需要继续更新。

# 只筛选包描述中属于 GitHub CLI 的 RPM 公钥
rpm -qa gpg-pubkey | xargs -I{} sh -c 'rpm -qi {} | grep -q "opensource+cli@github.com" && echo {}'

Debian/Ubuntu 直接替换 keyring

APT 用户不需要手工拼接新指纹，也不要关闭签名校验。重新下载官方 keyring 文件即可，关键是保存位置必须和 /etc/apt/sources.list.d/github-cli.list 里的 signed-by 一致。推荐位置不存在时先创建目录，并保证 APT 能读取该文件。

# 创建 APT keyring 目录，权限只覆盖目录本身
sudo mkdir -p -m 755 /etc/apt/keyrings

# 下载同时包含旧、新密钥的官方 keyring，并开放读取权限
sudo curl -fsSL -o /etc/apt/keyrings/githubcli-archive-keyring.gpg   https://cli.github.com/packages/githubcli-archive-keyring.gpg   && sudo chmod go+r /etc/apt/keyrings/githubcli-archive-keyring.gpg

# 先刷新仓库元数据，再安装或升级 gh
sudo apt update
sudo apt install gh

完成后再用 gpg --show-keys 检查，应该能看到新指纹。遇到 NO_PUBKEY 5612B36462313325、EXPKEYSIG 23F3D4EA75716059 等错误，优先检查实际 signed-by 路径是否仍指向另一份旧文件；不要只更新了一个未被 APT 使用的副本。

RPM 系发行版按包管理器刷新 repo

RPM 系统把公钥导入自己的 keyring，处理重点不是覆盖某个 APT 文件，而是重新获取官方仓库配置，使它引用更新后的 keyring。先运行 dnf --version 判断 DNF5 还是 DNF4，再选择对应命令。

# DNF5：Fedora 41 或更新版本，覆盖旧 repo 配置
sudo dnf config-manager addrepo --overwrite   --from-repofile=https://cli.github.com/packages/rpm/gh-cli.repo
sudo dnf update gh

# DNF4：Fedora 40 及更早版本或对应 RHEL/CentOS
sudo dnf config-manager --add-repo https://cli.github.com/packages/rpm/gh-cli.repo
sudo dnf update gh

执行升级时，包管理器可能询问是否导入 PGP key。确认新指纹是 7F38BBB59D064DBCB3D84D725612B36462313325 后再接受；旧指纹是 2C6106201985B60E6C7AC87323F3D4EA75716059。如果重复添加 repo 后仍报旧 key 错误，再按官方说明确认并移除对应旧的 gpg-pubkey 条目，然后重新安装 gh。

Docker 和自动化镜像要把 keyring 放在 apt update 之前

容器最容易把旧 keyring 固定在历史层里：前一层添加了 GitHub CLI 仓库，后一层才运行 apt-get update，于是宿主机已经修复，镜像构建仍然失败。控制 Dockerfile 时，在任何包列表更新之前重新拉取 keyring，并让后续层使用同一文件。

# 在执行 apt update 前刷新镜像内的官方 keyring
RUN wget -qO /etc/apt/keyrings/githubcli-archive-keyring.gpg     https://cli.github.com/packages/githubcli-archive-keyring.gpg     && chmod go+r /etc/apt/keyrings/githubcli-archive-keyring.gpg

# 如果镜像根本不需要 gh，则移除残留源，避免无关校验阻断构建
RUN rm -f /etc/apt/sources.list.d/github-cli.list

这两个动作按实际用途二选一：需要安装或升级 gh 就保留仓库并刷新 keyring；只是继承了带仓库的基础镜像，就删除源。不要以禁用 GPG 校验的方式绕过问题。

常见问题

Windows 或 macOS 需要更新这把 Linux 签名密钥吗？

不需要。这次公告针对 Linux APT/RPM 包仓库；Windows、macOS 和源码构建不使用这条 Linux 包签名路径。

通过 Homebrew 或 Conda 安装 gh 会受影响吗？

不受这次仓库密钥轮换影响。社区包管理器、Homebrew、Conda、GitHub Releases 的直接二进制包各自有独立的分发和校验方式。

keyring 里已经有新旧两把 key，还要重装 gh 吗？

通常不用。先确认 APT 的 signed-by 或 RPM 的 repo 配置确实引用了这份 keyring，然后重新运行包列表更新即可。