这个问题得从RPM包自身的校验机制和安全逻辑说起，咱们一步步拆解清楚：

• 先明确两个宏的核心差异
  %_pkgverify_level all会同时触发两个校验环节：一是验证RPM包的数字签名，二是验证包内文件的摘要哈希（比如MD5、SHA系列）；而%_pkgverify_level signature仅会验证数字签名。

• 为什么signature就足够覆盖安全需求？
  RPM的数字签名机制本身就已经包含了完整性校验的作用。简单来说，数字签名是基于整个RPM包的哈希摘要生成的——开发者用私钥对包的哈希值加密生成签名，用户用公钥解密后，会把解密得到的哈希和本地计算的包哈希对比。如果包被篡改过，本地计算的哈希就会和签名里的不一致，签名验证直接失败。
  正因如此，单独开启签名验证就已经同时保证了两点：①包是官方/可信来源发布的（真实性）；②包内容没有被篡改（完整性）。这也是很多讨论里说all冗余的原因——额外的摘要校验其实是重复劳动，没带来额外的安全增益。

• 结合CVE-2021-3445的修复逻辑来看
  这个漏洞是RPM在特定场景下的校验逻辑缺陷，修复方案里提到的两种配置都是为了强化校验，但signature是更高效的选择。如果只开启摘要校验，理论上存在被攻击者绕过的可能（比如篡改包内容后同时修改内置的摘要值）；但数字签名依赖私钥加密，攻击者没有发布方的私钥就无法伪造合法签名，从根源上杜绝了这种篡改风险。

• 和ISO校验流程的区别
  你提到的ISO校验需要分两步：先验CHECKSUM文件的签名，再用CHECKSUM验证ISO。这是因为ISO镜像本身没有内置签名信息，只能通过单独的校验文件来做二次验证。但RPM包是自带签名字段的，签名直接和包内容绑定，所以一次签名验证就完成了ISO校验里两步的工作，不需要额外再做摘要校验。

备注：内容来源于stack exchange，提问作者Waiho