应使用gpg --dearmor将https获取的官方公钥转为二进制keyring并绑定到源配置，而非弃用的apt-key或不安全的--recv-keys；密钥文件需存于/usr/share/keyrings/、权限644、属主root，并在sources.list中通过signed-by显式引用。
遇到 NO_PUBKEY 错误时怎么补救
直接从 apt update 报错里提取密钥 ID，比如 NO_PUBKEY 1234567890ABCDEF，就说明系统缺这个公钥。别急着用 apt-key，它已被弃用，且会把密钥无差别塞进全局信任池，权限模型混乱、审计困难。
正确做法是分两步走：先用 gpg 下载并转成二进制 keyring，再在源配置中显式绑定。
- 下载并转换密钥：
curl -fsSL https://example.com/pubkey.gpg | sudo gpg --dearmor -o /usr/share/keyrings/example-keyring.gpg
- 在
/etc/apt/sources.list.d/example.list中写明签名来源：deb [arch=amd64 signed-by=/usr/share/keyrings/example-keyring.gpg] https://example.com/debian stable main
- 运行
sudo apt update，错误应消失
为什么不能用 gpg --recv-keys 直接导入生产环境
因为 gpg --keyserver keyserver.ubuntu.com --recv-keys KEY_ID 从公共密钥服务器拉下来的密钥，没有身份绑定和完整性校验。攻击者可提前上传同 ID 的伪造密钥，或污染传输链路——这在中间人活跃的网络环境中风险极高。
官方仓库（如 Ubuntu、Debian）和可信第三方（如 Docker、GitLab）都提供 HTTPS 托管的原始 .gpg 或 .asc 文件，这才是唯一推荐的获取路径。
- 优先选官网文档明确给出的 URL，例如 Docker 官方始终用
https://download.docker.com/linux/ubuntu/gpg - 若只有密钥指纹，需离线比对：下载密钥文件后，用
gpg --show-keys pubkey.gpg查看指纹，手动核对是否与官网公布的一致 - 绝对避免在 CI/CD 流水线或自动化脚本中调用
--recv-keys，静默失败或污染密钥环会导致后续所有签名验证不可信
rpm 系统怎么让第三方 repo 生效
RHEL/CentOS/Fedora 不依赖 keyring 路径绑定，而是靠 .repo 文件里的 gpgkey 和 gpgcheck=1 联动生效。导入只是第一步，漏掉任一环节都会导致 gpgcheck 静默跳过或报错。
- 导入必须用
sudo rpm --import，支持本地文件或 HTTPS URL：sudo rpm --import https://repo.example.com/RPM-GPG-KEY-example
- 在
/etc/yum.repos.d/example.repo中确保包含：gpgcheck=1 gpgkey=https://repo.example.com/RPM-GPG-KEY-example
- 验证是否加载成功：
rpm -q gpg-pubkey | grep -i example；验证包签名：rpm -K package.rpm应输出gpg OK
验证密钥是否真正起作用的三个检查点
导入完成不等于信任链打通。很多问题出在“看起来成功了，但实际没生效”，关键要确认三处状态一致。
-
gpg --list-keys能列出密钥，只说明它进了用户密钥环，和包管理器无关 -
sudo apt-key list已废弃，不要用；Debian/Ubuntu 系统应检查/usr/share/keyrings/下对应.gpg文件是否存在且非空 - 最可靠验证方式：执行
apt update后查看输出中是否有Signing key will be used to verify release file类提示，或用apt-get check看是否报错
最容易被忽略的是：keyring 文件权限必须为 644，且属主为 root；否则 apt 会拒绝读取，但不会报错，只会降级为不校验——这种静默失效最难排查。
