GPG签名报错是系统主动拦截不可信软件包，需按NO_PUBKEY、EXPKEYSIG、BADSIG等关键词定位断点；Debian/Ubuntu应导入密钥至/usr/share/keyrings/并配置signed-by，RHEL系用rpm --import官网密钥，禁用验证仅限可信场景临时使用。
GPG 签名报错不是安装失败，而是系统在拦住你——它发现软件包的“数字身份证”不可信，于是主动拒绝加载。关键不是跳过验证，而是弄清哪一环断了：是根本没钥匙（NO_PUBKEY），钥匙过期了（EXPKEYSIG），还是钥匙和锁对不上（BADSIG）。下面分情况处理。
先看报错关键词，定位问题类型
运行 apt update 或 dnf makecache 后的错误里，重点关注这几个词：
-
NO_PUBKEY 后跟16位字母数字：系统压根没这个仓库的公钥，比如
NO_PUBKEY ED444FF07D8D0BF6 - EXPKEYSIG + 一串ID：公钥已安装，但有效期到了（如 2024-03-01），现在被标记为 expired
- BADSIG / NODATA / NO_PUBKEY 0x0000000000000000：常见于老系统（Ubuntu 16.04、Kali 2019 前），旧密钥体系已被弃用，需整体更新密钥环
- repomd.xml GPG signature verification error：多见于 RHEL/CentOS 的第三方源（如 PostgreSQL、MySQL），通常是密钥轮换或镜像同步滞后
Debian/Ubuntu/Kali 系统的标准修复方式
不推荐再用已废弃的 apt-key add，现代做法是把密钥存进 /usr/share/keyrings/ 并在源配置中显式引用：
- 下载官方密钥文件，例如 Kali：
wget -qO- https://archive.kali.org/archive-keyring.gpg | sudo gpg --dearmor -o /usr/share/keyrings/kali-archive-keyring.gpg - 编辑
/etc/apt/sources.list，把原来这行：deb http://http.kali.org/kali kali-rolling main
改成：deb [arch=amd64 signed-by=/usr/share/keyrings/kali-archive-keyring.gpg] http://http.kali.org/kali kali-rolling main - 如果是第三方源（如 GitLab、Docker），同样下载其
.asc或.gpg文件，放进/usr/share/keyrings/，并在对应sources.list.d/xxx.list中加上signed-by=路径 - 最后执行：
sudo apt clean && sudo apt update
RHEL/CentOS/Rocky/AlmaLinux 系统的处理方法
这类系统用 rpm --import 导入密钥，优先从官网获取最新 GPG 文件：
- PostgreSQL 官方密钥：
sudo rpm --import https://packages.postgresql.org/gpg.key - MySQL 2022 密钥（注意不是旧版）：
sudo rpm --import https://repo.mysql.com/RPM-GPG-KEY-mysql-2022 - 若提示密钥已存在但失效，先查旧密钥：
rpm -qa gpg-pubkey*
再卸载（ID 取后8位，如3a79bd29）：sudo rpm -e gpg-pubkey-3a79bd29-* - 更新元数据：
sudo dnf clean all && sudo dnf makecache
临时绕过验证仅限调试，慎用
仅当确认源绝对可信（如内网私有仓库、离线环境），且无法立即修复密钥时才考虑：
- 单次安装跳过：
sudo apt install xxx --allow-unauthenticated（Debian/Ubuntu）sudo dnf install xxx --nogpgcheck（RHEL系） - 禁用某仓库的 GPG 检查（不推荐长期）：
编辑/etc/yum.repos.d/xxx.repo，将gpgcheck=1改为gpgcheck=0 - 切勿全局关闭：
apt.conf或dirmngr配置中禁用 GPG 是高危操作，会削弱整个系统的安全基线
