[spring-projects/spring-boot]升级到 SnakeYAML 1.32

我希望它完全向后兼容

@asomov 此版本（1.32）是否修复了#32221中提到的有关日期的向后兼容性问题？

我在发行说明中没有找到它。

@kvmw 没有。这可能会带来更多困惑。但这是可能的（尤其是因为相应的 CVE 被认为是误报）

1.32 版本仍有 CVE-2022-38752 报告，这被认为是误报，但目前尚不清楚该漏洞是否已真正修复：https://bitbucket.org/snakeyaml/snakeyaml/issues/531/stackoverflow-oss-fuzz-47081#comment-64117937

无论如何，只要您不允许用户提供 YAML 输入（在标准 Boot 应用程序中，这取决于您如何部署配置），您就可以安全地忽略此 CVE。

这很奇怪。GitHub公告指出此问题已在 1.32 中修复，但Google 分配的 CVE未提及任何修复版本，因此NVD 没有在已知受影响的软件配置中限制版本。希望 NVD 能尽快修复此问题。

看起来 CVE 条目还远未修复，请参阅 github/advisory-database#667 中的讨论。

我认为首先存在一些关于它是否是真正的“漏洞”的争论（而不是在任意输入上使用 YAML 解析器所隐含的风险），但是我们暂时将其放在一边。CVE 似乎是（自动？）基于单个失败的 OSS Fuzz 测试 yaml 案例而提出的，并且该特定案例现在产生了 SnakeYAML 异常（关于在默认配置下使用递归键），而不是 OSS Fuzz 认为是拒绝服务的堆栈溢出。该 OSS Fuzz 问题现在被认为已通过他们的自动测试得到解决，因此我认为从 CVE 的角度来看将其视为“已修复”似乎是合理的，这是我向 NIST NVD 提出的论点。JVM 捕获的堆栈溢出是否实际上是拒绝服务似乎是一个合理争论的主题，但可能与减少此处的噪音不太相关。

用户是否继续使用 SnakeYAML 来解析完全不受信任的任意输入仍然是一个悬而未决的问题，以及 SnakeYAML 之类的东西应该在多大程度上保护用户/下游库免受自身的侵害（尤其是当与 YAML 规范冲突时），但这似乎又是另一个不同的争论。

在我昨天提交后，NVD 现已更新：https://nvd.nist.gov/vuln/detail/CVE-2022-38752我相信目前只有 OSSIndex 错误地标记了其中一些较新的漏洞。

除非我记错了，否则 Boot 2.7.6 仍在使用 SnakeYAML 1.30。难道不应该包括这个吗？

@OrangeDog 不，我们不是故意升级的，请参阅#32221

@bclozel 具体在哪里？https://github.com/spring-projects/spring-boot/issues/32221#issuecomment-1238030093表示您要更新到 >=1.31

@OrangeDog 我希望你现在已经熟悉我们的第三方升级政策。该评论是关于运行时兼容，而不是升级到 Spring Boot 维护版本中依赖项的新功能版本。

显然，我不熟悉 SnakeYAML 的版本控制策略。我以为 1.31 和 1.32 是错误修复版本。

@OrangeDog SnakeYAML 中没有需要修复的错误 - 有一个误报，在代码稍微修改后就消失了