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

Question

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

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

Answer 1

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

很多人认为,因为你必须签署提交给Maven的文件,所以软件可以信任.不幸的是,他们忽略的是,如果你不能确定签名库的密钥属于提供给Maven的原始源,那么签名就毫无意义.这似乎是Maven的情况.

解释变得简单

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

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

现在进行相同的类比以验证来自Maven的对象.Maven文档声称在上传的库上需要PGP签名(参考:将工件上载到中央存储库的指南)(尽管Sonatype声称许多旧包没有签名).可以想象驾驶执照类似于钥匙而且机票类似于Maven工件,并提出相同的问题:

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

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

其中第三个实际上是最容易做到的,因为它可以完全自动化(参见GPG快速入门指南,关于验证分离签名的部分).该部分无需人工干预.

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

那真的是威胁呢？

在人们发送包含可执行恶意软件的电子邮件并且NSA正在破坏SSL的世界中,认为这些相同的黑帽不是针对捆绑到世界各地的众多应用程序中的软件存储库是天真的.事实上,至少有三个严重的例子被抓住了.

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

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

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

简单来说(因为我已经喘不过气来了),我将引用两个来源,它们可以帮助指导您更好地选择第三方库.第一个是遵循Fortify攻击构建文件第5节中的建议,特别是包括安全审查过程.

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

Sonatype有什么用？

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

Answer 2

Jason提到了Sonatype的条款和条件.其中包含有关如何提交内容的链接:

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

该要求部分特别有趣.简而言之,所有提交者都应提供以下内容:

1. Javadoc和源代码
2. 对提交的文件进行数字签名
3. 更正项目元数据
   • GAV标识符(组,神器,版本)
   • 名称和描述字段以及项目URL
   • 从事该项目的开发人员
   • 许可证信息
   • 源代码存储库的位置

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

那么Sonatype从中得到了什么呢？

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

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

Answer 3

任何内容请阅读条款/服务： https: //repo1.maven.org/terms.html。如果之后你没有温暖和模糊，那么你可以不使用它。还有其他 Maven 存储库，但我在开发领域认识的大多数人都使用中央存储库并且从未遇到过问题。坦率地说，如果您不信任任何存储库，您很可能会放弃自己的存储库（例如 Artifactory）。

关于Sonatype。他们是一家有附加值的服务公司，中央回购或多或少是善意的。很多公司都有这种商业模式。说是鱼钩的诱饵。