有人设置maven存储库和/或ip流的伪装以提供原始的伪装库副本但注入恶意或有害代码的风险和可能性或场景是什么.
防止此类风险和可能性的步骤和做法是什么？
Sonatype 要求（非 SNAPSHOT 版本）工件是 GPG 签名的；公共 OpenPGP 密钥应上传到 (MIT) 密钥服务器。
但是任何人都可以通过电子邮件创建任何名称的任何 OpenPGP 密钥并将它们上传到密钥服务器。没有（据我所知；还是我错了？）没有自动机制来将特定的软件项目/库与特定的公钥相关联。当然，如果有人想检查工件的真实性，可以随时向软件作者索取公钥，或者密钥可能已经在某处发布（以将其与特定软件项目相关联的方式）；但由于这不能自动完成，几乎没有人会这样做。
因此，整个 OpenPGP 签名过程似乎也非常技术性和耗时，与其说实际上为普通用户提供了很多安全性，不如说是灌输一种虚假的安全感。
那么，难道不应该有一种自动/简化的方式将软件项目与 OpenPGP 密钥相关联，以使整个事情真正安全吗？
我想从Central手动验证Maven工件上的PGP签名,但我不知道从哪里开始.
我在Apache的指南中看到将工件上传到中央存储库,它说"我们要求您为所有工件提供PGP签名".
我已经看到Sonatype的Nexus Pro软件提到在Nexus Pro功能的博客文章中验证签名
但我无法找到有关如何手动获取签名的任何信息.我对GPG足够熟悉,可以执行实际验证.如何.asc在Central 获取工件文件？
我想强制执行严格的Maven依赖策略,该策略超出了基本checksumPolicy=fail方法.
这是尝试提供针对修改的版本依赖性的保护,该依赖性仍然具有有效的摘要值,也称为"依赖性链攻击".
这种情况可能来自以下情况:
在与其他开发人员的讨论中,一种解决上述问题的方法是在pom.xml中列出已知的MD5/SHA摘要,并让Maven验证下载的依赖项具有相同的摘要.这确保了只要源代码存储库保持安全,就会检测到已被破坏的任何包含的依赖项.
因此我的问题是双重的: