我们怎么知道我们可以信任Maven Central Repository？

Question

很抱歉，如果这个问题不适合StackOverflow，那么这不是编码问题。

我是Maven的新手，我很好奇如何可以免费获得Maven Central Repository。据我所知，它由一家名为SonaType的公司维护。他们资助吗？为什么？它是否可以作为其余业务的潜在客户工具？我想如果我理解他们的理由我会知道是否或如何/何时相信它。

Answer 1

很好的问题，特别是因为使用不安全的第三方库现在在OWASP Top 10中。不幸的是，大多数人都认为Maven Central的信任是理所当然的。我认为他们过于乐观了。

很多人认为，因为你必须签署提交给Maven的文件，所以软件可以信任。不幸的是，如果你不能确定签署该库的密钥属于提供给Maven的原始资源，那么签名就没有意义了。这似乎是Maven的情况。

解释变得简单

为简化说明，请考虑以下类比。当你去机场飞往某个地方时，你需要提供身份证明来证明你就是你所说的人。对于当地旅行，驾驶执照就足够了。检查您的身份证的人有几件事需要检查：

    
• SAME SOURCE：驾驶执照上的名字是否与机票上的名字相符？这可以防止奥萨马·本·拉登以巴拉克·奥巴马的名义预订机票。     
• 来源的真实性：驾驶执照上的图片看起来像是签到的人。这可以防止奥萨马·本·拉登窃取巴拉克·奥巴马的驾驶执照并使用它以他的名义办理登机手续。     
• 文件的真实性：驾驶执照是真实的。这可以防止奥萨马·本·拉登获得一张假冒​​驾驶执照，上面有他的照片，但另外还有巴拉克·奥巴马的名字。

现在进行相同的比喻以验证来自Maven的对象。 Maven文档声称在上传的库（尽管Guide to uploading artifacts to the Central repository）上需要PGP签名（参考：Sonatype claims many older packages do not have the signatures）。可以想象驾驶执照类似于钥匙而且机票类似于Maven工件，并提出相同的问题：

1. 相同来源：签署该库的密钥是否与签署该库的同一原始来源的某人相关联？
2. 来源的真实性：我们能否验证该密钥确实属于签署该密钥的同一原始来源？
3. 文件的真实性：工件（库）上的PGP签名是否有效签名？

为了检查相同的源，只需从密钥服务器下载与工件关联的公钥，并验证它是否来自与原始源关联的电子邮件地址。例如，这可以在MIT PGP keyserver完成。有关如何完成此操作的具体详细信息，请参阅Verify Dependencies using PGP。

其中第三个实际上是最容易做到的，因为它可以完全自动化（参见GPG quickstart guide, section on verifying detached signatures）。这部分不需要人工干预。

第二部分是差距所在。即使签名签出并且MIT密钥服务器声称密钥与原始源相关联，我们如何知道它确实是由原始源而不是其他人创建的？实际上，出于演示目的，我在MIT密钥服务器上为Mickey Mouse创建了一个密钥。我可以轻松创建一个似乎与oracle.com或spring.io或whitehouse.gov相关联的密钥。

那真是什么威胁？

在人们发送包含可执行恶意软件的电子邮件并且NSA正在破坏SSL的世界中，认为这些相同的黑帽不是针对捆绑到世界各地的众多应用程序中的软件存储库是天真的。事实上，有at least three serious examples that were caught。

所以要清楚，如果我是黑帽子，这就是我要做的事情（记录：我不是黑帽子!!!）。我会采用广泛使用的开源软件包。然后我会将我的后门隐藏到包的源代码中并在本地构建它。下一步是创建与原始源的电子邮件地址关联的密钥对。我将该密钥上传到MIT密钥服务器（它接受电子邮件地址而不进行任何验证），然后签署我的恶意软件包。最后，我将恶意软件包和签名一起上传到Maven并窃笑，因为我的恶意软件在全世界一点一点地被采用。我声称不太可能很快发现这次攻击。

您可以如何信任从Maven下载的软件？

不幸的是，没有简单的答案。信任您正在使用的软件的次数越多，您的工作效率就越低。您需要进行实际的权衡，以平衡安全性和生产力。

要简短（因为我已经喘不过气来了），我将引用两个来源，它们可以帮助指导您更好地选择第三方库。首先是遵循Fortify Attacking the Build文件第5节中的建议，特别是包括安全审查程序。

第二个建议是Sonatype有一个名为CLM的产品，它可以帮助您的公司分析您正在使用的软件，包括提供有关已知缺陷的信息以及有多少其他组织正在使用相同的产品。

它为Sonatype的内容是什么？

除了可以销售的Sonatype的Nexus和CLM产品外，还值得阅读this article。 Sonatype正在引领软件开发效率与开源解决方案信任之间的平衡。他们还没有完全解决所有问题（不会透露我与他们交换的私人电子邮件），但他们正朝着正确的方向前进。

Answer 2

杰森提到了Sonatype terms and conditions。其中包含有关如何提交内容的链接：

• http://central.sonatype.org/pages/ossrh-guide.html

requirements部分特别有趣。简而言之，所有提交者都应提供以下内容：

1. Javadoc和源代码
2. 对提交的文件进行数字签名
3. 更正项目元数据
   • GAV标识符（组，工件，版本）
   • 名称和说明字段以及项目网址
   • 从事该项目的开发人员
   • 许可证信息
   • 源代码存储库的位置

此信息发布了您和我需要了解的有关代码，构建方式以及更重要的构建代码的所有内容。使用GPG使我们能够验证二进制文件是由项目POM文件中所述的开发人员构建的。此外，Maven Central会自动生成SHA校验和，使您能够验证构建过程下载的文件的完整性。

那么Sonatype从中得到了什么？

1. 在销售其存储库托管软件的专业版时，它是一个很好的宣传工具。
   • 一个有用的专业功能是限制可能从Maven Central下载的工件。有助于执行有关第三方软件的标准或疑虑。
2. Maven Central已成为全球最大的开源Java软件存储库。 Sonatype使用它为他们的企业客户提供了许多products。
   • 这些提供了有关公司软件使用的第三方库的安全漏洞的详细报告。令人印象深刻的是，这些工具可以直接集成到软件开发和构建过程中。
   • Sonatype还可以提供与其代码的第三方依赖关系相关的软件许可的报告。对于合规性非常重要，如果没有这种工具，在实践中很难做到。

希望这会有所帮助。我最后指出Sonatype正在做的事情与其他开源软件包装计划没什么不同。 Redhat，Debian和Canonical花费了大量精力打包软件，以便通过操作系统安全可靠地进行分发。 Maven Central可能更适合开发人员。

Answer 3

有任何内容阅读条款/服务：http://repo1.maven.org/terms.html。如果你之后没有温暖和模糊，那么你可以自由地不使用它。还有其他的maven repos，但我在开发世界中认识的大多数人使用中央回购并且从未遇到过问题。坦率地说，如果你不相信任何一个回购，你就可以把你自己的回购（Say Artifactory）扔掉。

关于SonaType。他们是一家具有附加值的服务公司，而Central Repo或多或少都是好的。很多公司都有这种商业模式。说钩子的诱饵。

推荐 - ＆gt;使用Central Repo GRINS 时，确保打开锡纸帽。好。那里只是一个小笑话。