gpt4 book ai didi

maven - 在基于 Maven POM 的自动构建系统中验证依赖项真实性

转载 作者:行者123 更新时间:2023-12-03 23:48:34 24 4
gpt4 key购买 nike

我刚刚被指向一个非常有趣的article ( archived ) 关于名为
交叉构建注入(inject) (XBI)。基本上,它是走私不良代码的花哨名称
在构建时通过 ant、maven 或 ivy 等自动构建系统进入应用程序。
这个问题可以通过引入加密签名验证来缓解依赖关系,因为它目前已在许多操作系统中用于下载包。
需要明确的是:我不是在谈论简单地为 Artifact 提供 md5 或 sha1 哈希。这已经完成了,但是这些哈希存储在与 Artifact 相同的位置。因此,一旦恶意黑客破坏了存储库并可以替换 Artifact ,他们也可以替换哈希值。
所以真正需要的是某种 PKI,它允许开发人员签署他们的 Artifact 和 maven 来验证这些签名。由于签名是使用开发人员的私钥完成的,因此只有存储库被破坏时,它不能被篡改。
有谁知道这个在maven中的状态?

最佳答案

tl;博士 :

Maven 中不存在的验证机制和 POM 的 DSL 中缺少语言结构是严重的安全威胁。直到 MNG-6026已解决,请使用类似 Gradle Witness .

介绍

到目前为止提供的答案似乎都没有解决问题。 签署 Artifact 只是第一步 进入正确的方向。但是,用于签署 Artifact 的 key 被认为是可信/有效的条件是非常不透明的。例如:pgpverify-maven-plugin 怎么办?或 Nexus Professional实际验证签名对 Artifact 有效吗?仅从 key 服务器检索 key 并验证 Artifact 是不够的。

Sonatype 在他们的 blog post 中简要提到了这一点。 :

PGP Signatures: Another Level

On the consumption side, you can use Procurement in Nexus Professional to check for the presence of a signature, and on the publishing side signing your releases with a PGP signature and making PGP signatures available on a public keyserver will help people double-check that artifacts and checksums are consistent. Note: I think there’s more work to be done to create tools that encourage the use of PGP keys and, more importantly, give repository administrators some control over what keys are to be trusted.



(强调我的)

使用信任信息扩展项目对象模型 (POM)

我们需要的是建模从您的项目或 Artifact 到声明的依赖关系的信任关系的可能性。因此,如果所有相关方都声明了这种关系,我们就能够创建一个“信任链”,从根(例如项目)到其依赖关系,一直到最后一个传递依赖关系。 Project Object Model (POM)需要通过 元素扩展依赖项。

现在的情况

现在我们有类似的东西
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.0</version>
</dependency>

硬依赖

对于硬依赖, 可以包含 artifact 的 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>

软依赖

如果使用软依赖或范围依赖,那么我们可以指定用于签署 Artifact 的 key 对的公钥(或多个)
<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>

现在?

感谢 peter触发我,我提出了 Apache Maven 的功能请求: MNG-6026 .让我们看看接下来会发生什么。

其他方法

Gradle Witness为 gradle 做类似的事情。但它有一些缺点:
  • 它建立在 gradle 之上(并内置于 POM)
  • 它只允许硬依赖,因为它使用哈希。

  • Maven Enforcer Plugin 似乎也是如此。 .

    pgpverify-maven-plugin显然也遵循这种方法。虽然缺少文档,但有一个 test for a so called keysMap property , 这也是 appears in the config file as keysMapLocation .

    关于maven - 在基于 Maven POM 的自动构建系统中验证依赖项真实性,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/3307146/

    24 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com