GitHub CLI 的 Linux 套件金鑰 9/5 到期：哪些人會更新失敗、怎麼在壞掉前修好【2026 實查】

如果你是在 Linux 上用 apt install gh 或 dnf install gh 裝 GitHub CLI 的人，這則消息跟你有關：GitHub 官方在 2026-09-03 的 Changelog 公告，gh 的 Linux 套件庫簽章金鑰在 2026-09-05 到期。

先講結論：多數人不用做事，但有一群人不處理就會在下一次更新時看到驗簽錯誤。這篇用白話說清楚「你是不是那群人」。

一、先講白話：這件事到底在說什麼

Linux 的套件管理員（APT、RPM）在下載軟體時，會用一把公開金鑰去驗證「這包東西真的是 GitHub 發的、中途沒被換掉」。這是防止有人在你更新時偷塞假套件的機制。

那把金鑰有有效期限。GitHub 這把 9 月 5 日到期，所以他們早在 2026 年 4 月就發布了一份新的鑰匙圈（keyring），裡面同時放了「現在這把」和「接替的那把」。

依官方說法：該日之後的第一次發布開始，APT／RPM 的套件庫索引與新發布的 RPM 套件，就只會用接替的那把新金鑰簽名。

換句話說：你的機器上如果只有舊金鑰，之後抓到的索引就驗不過。

二、誰要動手、誰不用

需要處理的人（官方原文條件）：在 2026-04-08 之前從官方 APT 或 RPM 套件庫安裝 GitHub CLI，而且從那之後沒有更新過安裝設定的人。這些機器上的鑰匙圈很可能只有舊金鑰。

完全不受影響的人（官方明列）：

• Windows 使用者
• macOS 使用者
• 自行從原始碼編譯的人
• 用 Homebrew、Conda 或社群套件管理員安裝的人
• 直接下載 .deb 檔或從 GitHub Releases 抓獨立執行檔的人

也就是說，這是只影響「官方 apt／rpm 套件庫」這一條安裝路線的事。

三、怎麼確認自己有沒有中招

最直接的方式是跑一次更新看有沒有驗簽錯誤。以 Debian／Ubuntu 為例：

sudo apt update

如果出現類似「NO_PUBKEY」「signatures couldn’t be verified」「key has expired」這類字眼，而且來源指向 GitHub CLI 的套件庫，那就是這件事。

實際的換金鑰指令，請直接照 GitHub 官方公告內的說明操作——官方公告會給當下正確的金鑰位址與指紋，這種東西照第三方部落格的舊指令貼，反而容易貼到過期或錯誤的來源。這也是為什麼我們這篇不自行編一組指令給你：驗簽相關的步驟只該從官方來源複製。

四、不處理會怎樣

不會馬上壞。你已經裝好的 gh 指令仍然可以用。

真正的影響是：

1. 之後 apt update 會對這個套件庫報錯，而且很多人的更新腳本會因為一個來源失敗就整個中止，連帶影響其他套件更新。
2. 你收不到 gh 的新版，包括之後的安全性修補。
3. 在 CI／伺服器環境上，這種錯誤常常是「某天早上流水線突然紅了」才被發現的類型——而那時你通常在趕別的事。

五、我們的看法：這是「金鑰輪替」的正常操作，重點在時間差

金鑰會到期是設計上刻意的，不是出事。GitHub 的處理其實算標準做法：提前約五個月（4 月）就把新舊兩把金鑰一起發出去，讓正常更新的機器在不知不覺中就換好了。

會出問題的只有「裝完就沒再動過」的機器——而這種機器在公司內部往往最多：某台跑了兩年的建置伺服器、某個 base image、某個沒人想碰的舊容器。

建議動作：不要只修你自己的筆電。翻一下你手上的 Dockerfile、Ansible／Puppet 設定、CI 的 image，看看有沒有硬寫死 GitHub CLI 套件庫金鑰的地方——那些才是 9 月 5 日之後會安靜壞掉的地方。

本文事實依據為 GitHub 官方 Changelog（2026-09-03），查核日 2026-09-07；換金鑰的實際指令請以官方公告當下內容為準。GitHub Copilot 的方案與價格整理見我們的 GitHub Copilot 工具頁。