er4*_*z0r 12 security build-automation pom.xml maven
我刚刚指出一篇非常有趣的文章,关于一个名为Cross Build Injection(XBI)的安全问题.基本上,它是一个奇特的名称,通过自动构建系统(如ant,maven或ivy)在构建时将不良代码走私到应用程序中.
通过引入加密签名验证可以缓解这个问题,因为它目前已经存在许多用于下载包的操作系统.
要明确:我不是在谈论简单地为工件提供md5或sha1哈希.这已经完成,但这些哈希值存储在与工件相同的位置.因此,一旦恶意黑客破坏了存储库并且可以替换工件,他们也可以替换哈希.
因此,实际需要的是某种PKI,它允许开发人员签署他们的工件和maven以验证这些签名.由于签名是使用开发人员的私钥完成的,因此只有存储库被泄露时才能被篡改.
有没有人知道这个在maven中的状态?
tl;博士:
Maven中不存在的验证机制和POM DSL中缺少的语言结构是严重的安全威胁.在解决MNG-6026问题之前,请使用像Gradle Witness这样的方法.
迄今为止提供的答案似乎都没有解决问题.签名工件只是迈向正确方向的第一步.但是,用于对工件进行签名的密钥被认为是可信/有效的情况非常不透明.例如:pgpverify-maven-plugin或Nexus Professional如何实际验证签名对工件是否有效?只是从密钥服务器检索密钥并验证工件是不够的.
Sonatype在他们的博客文章中简要提到了这一点:
PGP签名:另一个级别
在消费方面,您可以使用Nexus Professional中的Procurement检查是否存在签名,并在发布方使用PGP签名对您的版本进行签名,并在公钥服务器上提供PGP签名,这将有助于人们仔细检查该工件和校验和是一致的.注意:我认为还有很多工作要做,以创建鼓励使用PGP密钥的工具,更重要的是,让存储库管理员可以控制哪些密钥是可信任的.
(强调我的)
我们需要的是建模从项目或工件到声明的依赖关系的信任关系的可能性.因此,如果所有相关方都宣布这样的关系,我们就能够从根(例如项目)创建一个"信任链",而不是依赖于最后的传递依赖.的项目对象模型(POM)需要通过对依赖关系的<验证/>元素进行扩展.
现在我们有类似的东西
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.0</version>
</dependency>
Run Code Online (Sandbox Code Playgroud)
对于硬依赖,<verfication />可能包含sha256sum工件及其POM文件:
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.0</version>
<verification>
<checksum hash='sha-256'>
<pom>[sha256 of junit pom file]</pom>
<artifact>[sha256sum of artifact (junit.jar)]</artifact>
</checksum>
</verification>
</dependency>
Run Code Online (Sandbox Code Playgroud)
如果使用soft或ranged依赖项,那么我们可以指定用于对工件进行签名的密钥对的公钥(或多个)
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>[4.0,4.5)</version>
<verification>
<openpgp>[secure fingerprint of OpenPGP key]</openpgp>
<!-- possible further 'openpgp' elements in case the artifacts in the
specified version range where signed by multiple keys -->
</verification>
</dependency>
Run Code Online (Sandbox Code Playgroud)
感谢peter触发了我,我已经为Apache Maven提出了一个功能请求:MNG-6026.让我们看看接下来会发生什么.
Gradle Witness对gradle做了类似的事情.但它有一些缺点:
Maven Enforcer插件似乎也是如此.
pgpverify-maven-plugin似乎也遵循这种方法.虽然缺少文档,但是对所谓的keysMap属性进行了测试,该属性也出现在配置文件中keysMapLocation.
更新:下面提到的校验和确实仅用于完整性检查,并且确实与工件一起存储,因此它们无法回答问题。
实际上,需要使用PGP对工件进行签名以将其上传到与Central同步的存储库中(Maven GPG插件可以帮助完成此步骤)。要在下载时验证签名,请您使用支持此功能的存储库管理器。从如何使用Maven生成PGP签名:
如果使用从Central Maven存储库下载工件的工具,则需要确保您正在努力验证这些工件具有可针对公共密钥服务器进行验证的有效PGP签名。如果您不验证签名,则不能保证下载的是原始工件。验证工件签名的一种方法是使用Nexus Professional之类的存储库管理器。在Nexus Professional中,您可以配置采购套件,以检查每个下载的工件是否有有效的PGP签名,并针对公共密钥服务器验证签名。
如果使用Maven开发软件,则应为发行版生成PGP签名。发行带有有效签名的软件意味着您的客户可以验证软件工件是由原始作者生成的,并且在运输过程中未被任何人修改。大多数大型OSS伪造文件,例如Apache Software Foundation,都要求所有项目都由发布管理器发布,发布管理器的密钥已由组织的其他成员签名,并且如果您要将软件工件同步到Maven Central,则需要 提供pgp签名。
可以将Maven安装插件配置为创建完整性校验和(MD5,SHA-1),并且可以为每个存储库配置校验和策略(请参阅参考资料checksumPolicy)。
Maven存储库管理器可以/应该也可以处理它们。参见例如:
| 归档时间: |
|
| 查看次数: |
3821 次 |
| 最近记录: |