共计 1179 个字符，预计需要花费 3 分钟才能阅读完成。
文 | 局长 \
出品 | OSC 开源社区（ID：oschina2013）
来自 Google Open Source Insights Team 的平安钻研人员通过考察 Maven Central 中所有软件包的所有版本，以更好地理解最近曝出的 Log4j 破绽对整个 JVM 语言生态系统的影响，同时还跟踪了正在进行的缓解受影响软件包的工作。
钻研人员发现，截至 2021 年 12 月 16 日，来自 Maven Central 的 35,863 个可用软件包依赖于存在破绽的 log4j 代码。这意味着 Maven Central 上超过 8% 的软件包至多有一个版本受破绽影响（此数字不包含所有 Java 软件包，例如间接散发的二进制文件）
就生态系统影响而言，8% 是相当微小的数字。因为对 Maven Central 生态的均匀影响数值为 2%，中位数则低于 0.1%。
如记录破绽的 CVE 所述，大多数受影响的软件包来自间接依赖项（即本身依赖项的依赖项），也就是说它们没有将 log4j 明确定义为依赖项，而是作为传递依赖项被引入进来。
这正是 JVM 生态整体上修复此破绽异样艰难的起因。平安钻研人员称，在撰写文章时，只修复了近五千个受影响的软件包，还有 30000 多个软件包会受到破绽的影响。
简略来说就是，破绽在依赖关系链中嵌套得越深，修复破绽所需的步骤就越多。下图显示了受影响的 log4j 包（外围或 api）首次呈现在依赖图中的深度的直方图。对于超过 80% 的软件包，该破绽的深度超过一级，其中大多数受影响的级别降落了 5 个级别（有些甚至降落了 9 个级别）。这些包将须要在依赖树的所有局部进行修复，而且首先从最深处的依赖关系开始。
修复破绽的另一个艰难之处由解析算法 (resolution algorithm) 和需要标准约定中生态系统层级的抉择引起。
在 Java 生态中，开发者通常的做法是指定软件版本方面的“软”要求——假如没有其它版本的雷同包呈现在依赖关系图中，解析算法会应用指定的明确版本。对于此类修复，通常须要维护者采取更加明确的口头，以将依赖需要更新为修补后的版本。这种做法与其它生态造成了显明的比照，例如在 npm 软件包中，开发者通常会为依赖项指定凋谢范畴。凋谢范畴容许解析算法抉择满足依赖性要求的最近公布的版本，从而引入新的修复。
最初，对于整个生态须要消耗多少工夫来实现破绽修复，目前也很难评估。在查看了所有公开披露的受影响 Maven 软件包中，平安人员发现只有不到一半（48%）失去了修复。
参考：https://security.googleblog.c…
近期热文举荐：
1.1,000+ 道 Java 面试题及答案整顿 (2021 最新版)
2. 劲爆！Java 协程要来了。。。
3. 玩大了！Log4j 2.x 再爆雷。。。
4.Spring Boot 2.6 正式公布，一大波新个性。。
5.《Java 开发手册（嵩山版）》最新公布，速速下载！
感觉不错，别忘了顺手点赞 + 转发哦！
