Maven Artefacts - 为什么使用 PGP 签名和 md5/sha1 哈希？

问题描述

为什么存储库需要 pgp 签名和 MD5/SHA1 哈希？难道pgp签名还不够吗？

在 maven 中央存储库上，对于每个人工制品，都有一个：

1. .asc 文件 - 对应于该人工制品的 pgp 签名。
2. .md5 文件 - 包含人工制品的 MD5 摘要。
3. .sha1 文件 - 包含人工制品的 SHA1 摘要。
4. .asc.md5 文件
5. .asc.sha1 文件。

例如，您可以查看此出版物：https://repo1.maven.org/maven2/org/typelevel/cats-core_2.13/2.4.1/
我不太确定 .asc.md5 和 .asc.sha1 代表什么文件。这些摘要是用签名的私钥加密的吗？

我的推理如下：

1. 我了解 MD5 和 SHA1 摘要的价值。它允许您检查您下载的人工制品是否未损坏。为此，您可以自己计算（下载的人工制品的）摘要，并将其与相应的公共摘要进行比较。
2. 我也很欣赏这并不能保证人工制品的真实性。作为“中间人”可能会为您提供受骗的人工制品和相应的受骗的 .md5 和 .sha1 文件。我也知道 maven central 上的 https 不能解决这个问题，例如你可以通过代理访问它。
3. 我的理解是 pgp 签名通过以下机制解决了上述问题

人工制品的创造者
PGP(original-artefact,privateKey) = .asc 文件
据我所知，.asc 文件是签名。这基本上是人工制品的摘要，它使用私钥加密，并添加了一些元信息，即哈希算法。

MavenClient
PGP（下载的人工制品，公钥，.asc 文件）

1. 使用用于计算签名摘要的相同哈希函数计算他下载的人工制品的摘要。我假设这作为元数据存储在签名本身（.asc 文件）上。
2. 使用公钥解密包含的摘要。
3. 比较第 1 步和第 2 步中的摘要。

因此，我想说，如果摘要匹配，那么我们验证了人工制品的真实性，但我们也验证了它没有被损坏。否则，摘要会有所不同。对吗？

那么这就引出了一个问题。为什么我们需要额外的 .md5 和 .sha1 文件？

作为奖励问题。为什么不需要将公钥也存储在 maven 上？这不是让事情更清楚吗？就目前而言，您没有验证真实性所需的所有文件/数据。您必须从 pgp 服务器获取公钥。

所以，总结一下，我有以下 3 个问题：

1. 为什么 maven central 需要人工制品的 pgp 签名和 md5/sha1 哈希？为什么 pgp 签名还不够？
2. 文件 .asc.md5 和 .asc.sha1 代表什么？
3. 为什么不将公钥与其他所有内容一起存储？

解决方法

https://maven.apache.org/repository/guide-central-repository-upload.html

引用上述 (1) 的指南：

为了提高中央存储库的质量，我们要求您为所有工件（所有文件校验和除外）提供 PGP 签名。

据我所知，任何工件（例如 JAR、ZIP、TAR 等）都必须签名。 md5 或 sha1 等校验和不需要签名。

(2) 它们是签名的校验和。特别是对于 Gradle，Signing plugin 标记所有输出。例如，MavenPublication 通常输出 POM 和 JAR 工件。当签名插件被指示对发布进行签名时，它会生成校验和文件并为每个工件对它们进行签名。

请注意，您可以禁用一些校验和：https://docs.gradle.org/6.0.1/release-notes.html#publication-of-sha256-and-sha512-checksums

(3) 将您的公钥发布到 Maven 存储库是不寻常的。虽然我不相信有什么能阻止你。虽然因为它会被视为任何工件，你需要签署它......这没有意义。