科技 · 實用指南
APT 顯示 NO_PUBKEY？先核驗套件庫，再用 Signed-By 修復金鑰設定
先將錯誤對應到實際啟用的來源，核驗發布者與完整指紋，再檢查金鑰格式、_apt 權限及 Signed-By，最後確認同一套件庫恢復簽章驗證。
APT 的 NO_PUBKEY 表示：套件庫中繼資料的簽章所用金鑰，APT 無法在該來源的設定下使用。這不代表論壇或金鑰伺服器上的某把金鑰正確，也不是關閉簽章檢查的理由。
安全修復應限於特定套件庫：保留錯誤、定位來源項目，透過發布者官方管道核驗套件庫身分與完整指紋，使用格式正確的專用金鑰環，以 Signed-By 綁定，再不帶任何信任繞過選項重跑更新。
1. 修改信任之前，保留完整錯誤
再次正常執行更新並保存完整輸出，記錄 NO_PUBKEY 識別碼、套件庫 URL、suite 或發行代號，以及錯誤指向 InRelease 還是 Release.gpg。先不要新增金鑰。多個第三方來源可能同時產生無關警告；應依主機名稱與 suite 定位，而非訊息的先後順序。
檢查 /etc/apt/sources.list，以及 /etc/apt/sources.list.d 中 APT 識別的 .list 與 .sources 檔案。閱讀完整匹配行或 deb822 段落，包括 URIs、Suites、Signed-By、Enabled。註解的 .list 行與 Enabled: no 段落已停用，其他副檔名的備份並非啟用項目。對應錯誤 URL 和 suite，記錄所有啟用的重複項；遞迴搜尋只能協助定位，不能證明 APT 載入了該設定。
2. 區分發行版官方與第三方套件庫
預設安裝的 Debian、Ubuntu 已透過發行版維護的金鑰環套件提供官方金鑰。官方套件庫缺少金鑰，可能涉及金鑰環過舊、版本不再受支援、來源填寫錯誤或安裝損壞。先確認系統版本與官方 URL，再考慮手動下載。
第三方套件庫應使用廠商官方設定頁面或金鑰發布文件。若無法獨立確認套件庫 URL、發布者身分與公布的完整指紋之間的關係，就停用該來源。任意匯入金鑰可能改變錯誤，卻不能證明誰控制套件庫。
3. 安裝之前，核驗完整指紋
只從已確認的發布者管道將候選公鑰下載至暫存檔。用 `gpg --show-keys --with-fingerprint --with-subkey-fingerprint /path/to/candidate-key` 檢視，不加入受信任金鑰環。將完整主金鑰指紋逐字元與套件庫所有者另一官方頁面公布的指紋比較。
末尾八位或十六位與 NO_PUBKEY 識別碼一致，不足以批准金鑰。金鑰伺服器結果、論壇命令、重新導向位址和熟悉的使用者標識，也不能證明發布者身分。若官方公告金鑰輪替，先記錄舊、新指紋及適用操作說明。
4. 使用格式正確的專用金鑰環
需要時建立 /etc/apt/keyrings，由 root 擁有，並允許穿越目錄。ASCII 裝甲公鑰使用 .asc，匯出的二進位 OpenPGP 金鑰環使用 .gpg。Debian 文件明確區分現代 GnuPG keybox 與 APT 金鑰環；不要複製私人 GnuPG 主目錄或 keybox。
核驗指紋後，只安裝公鑰資料，使用套件庫專用檔名、root 擁有者與 0644 權限。用 file、gpg --show-keys --with-fingerprint、stat，以及 `sudo -u _apt test -r /etc/apt/keyrings/vendor-archive-keyring.asc` 檢查。若最後一項失敗，用 namei -l 檢查所有上層目錄；檔案可讀但目錄無法穿越，_apt 仍不能存取。
5. 用 Signed-By 限定套件庫金鑰
對 deb822 .sources，在已核驗 URI 與 suite 的段落加入 `Signed-By: /etc/apt/keyrings/vendor-archive-keyring.asc`。舊式 .list 則將 `signed-by=/etc/apt/keyrings/vendor-archive-keyring.asc` 放入 deb 後的選項方括號。使用實際安裝的 .asc 或 .gpg 檔名，副檔名應符合金鑰表示形式。
Signed-By 限定可認證該套件庫的金鑰，比將所有第三方金鑰放入全域信任更有界線，但不保證套件無害。逐庫遷移並備份原項目；限定來源驗證成功前，不要移除舊全域金鑰。引用檔案若有多把公鑰而未指定指紋，檔內金鑰都會獲准；檢查完整檔案並遵循發布者的金鑰選擇說明，不信任來歷不明的集合。
6. 驗證套件庫，不只看結束碼
不帶不安全選項執行 `sudo apt-get update`。目標套件庫應能取得並認證中繼資料，不再出現 NO_PUBKEY、無效簽章或金鑰環不可讀訊息。成功輸出的主機名稱與 suite 應和起初定位的一致；其他鏡像成功不證明原失敗項目已修復。
對預期來自該庫的套件執行 `apt-cache policy PACKAGE_NAME`，確認候選版本與來源符合預期。記錄來源檔案路徑、套件庫 URI 與 suite、已核驗的完整指紋、安裝的金鑰環路徑與 SHA-256、權限、更新結果和套件來源檢查，方便日後輪替及異常調查。
7. 失敗時排查，保持認證開啟
指紋不同、官方頁面無法取得、金鑰過期或撤銷卻無替代說明，或套件庫身分突然改變，都應停用並聯絡發布者。指紋相符仍顯示 NO_PUBKEY，則重新檢查 Signed-By 路徑、格式、_apt 可讀性、重複來源，以及 Release 中繼資料是否真的由該金鑰簽署。
trusted=yes、allow-insecure=yes、Acquire::AllowInsecureRepositories 或未認證的安裝，會降低觸發問題的認證控制。Debian 將這些方式描述為降低安全性的例外，不是修復金鑰的步驟。發布者、金鑰與簽署的中繼資料形成可核驗鏈條之前，保持該庫停用。
