apt update能完成，但结尾提示Key is stored in legacy trusted.gpg keyring。这表示某个第三方仓库仍依赖旧的全局密钥环，当前不一定更新失败，但信任边界过宽且apt-key已经弃用。
迁移重点不是隐藏警告，而是让每个仓库只信任自己的签名密钥。
旧密钥环为什么会被警告
/etc/apt/trusted.gpg与trusted.gpg.d中的密钥默认可为多个仓库提供信任。官方推荐由系统管理员添加的第三方密钥放在/etc/apt/keyrings，并通过软件源的Signed-By绑定到特定仓库。
全局受信任密钥一旦被滥用，影响范围可能超过原本对应的仓库。
确认仓库与密钥指纹
从APT警告和软件源文件确定仓库域名，再从厂商官方HTTPS页面取得当前公钥与指纹。可用gpg --show-keys --with-fingerprint 文件检查下载的密钥，不要仅凭短Key ID判断身份。
不要从搜索结果、论坛附件或未验证的密钥服务器直接导入生产密钥。若旧密钥与官方指纹不一致，应先停用该仓库并调查。
创建独立keyring文件
创建/etc/apt/keyrings后，把ASCII armored密钥保存为.asc，或用gpg --dearmor转换成二进制.gpg。文件应由root管理并可被_apt用户读取，常见权限为0644。
APT 2.4及以后明确提供/etc/apt/keyrings作为管理员密钥的推荐位置；更旧环境要先核对APT版本与支持格式。不要把私钥放进APT keyring。
在软件源中绑定Signed-By
传统单行格式可在deb后添加[signed-by=/etc/apt/keyrings/厂商.gpg]；DEB822格式则使用Signed-By: /etc/apt/keyrings/厂商.gpg。修改前先备份对应.list或.sources文件。
不要使用trusted=yes跳过签名验证。迁移后也不要立刻删除整个旧密钥环，其中可能还包含其他仓库正在使用的密钥。
更新与验收
执行apt update确认旧密钥环警告消失、签名验证成功，再用apt-cache policy核对关键软件包来源。可在萤光云或LightNode的同版本VPS先演练。验收标准是仓库可更新、指纹匹配、Signed-By路径生效且其他软件源未受影响。
FAQ
问：把密钥复制到trusted.gpg.d就算完成迁移吗？答：可以避开单一旧文件，但仍属于全局信任；更推荐独立keyring配合Signed-By。
问：警告出现后还能继续apt upgrade吗？答：应先确认仓库和密钥可信。警告不等于签名失效，但长期忽略会增加后续升级与安全风险。
温馨提示
温馨提示：软件源密钥应记录来源、指纹和有效期。自动化配置中同步更新keyring与源文件，避免下一次部署又把旧apt-key写法恢复。
