Comment From: asomov
I hope it is fully backwards compatible
Comment From: kvmw
@asomov is this version (1.32) fixes the backward compatibility issue, regarding dates, which was mentioned in #32221 ?
I didn't find it in release notes.
Comment From: asomov
@kvmw no it did not. It may bring even more confusion. But it is possible (especially because the corresponding CVE is considered a false positive)
Comment From: OrangeDog
CVE-2022-38752 is still reported for 1.32, which is argued to be a false positive, but it is unclear whether the vulnerability has actually been fixed: https://bitbucket.org/snakeyaml/snakeyaml/issues/531/stackoverflow-oss-fuzz-47081#comment-64117937
In any case, as long as you don't allow user-provided YAML input (which in a standard Boot app depends how you're deploying your config) you can safely ignore this CVE.
Comment From: bclozel
That is rather strange. The GitHub advisory states that this is fixed in 1.32, but the CVE assigned by Google doesn't mention any fix version, so NVD didn't not restrict the version in the known affected software configurations. Hopefully this will be fixed soon by NVD.
Comment From: bclozel
It looks like the CVE entry is far from being fixed, see discussion in github/advisory-database#667.
Comment From: chadlwilson
I think there is a bit of debate about whether it's a real 'vulnerability' in the first place (rather than risk implicit in using a YAML parser on arbitrary input), however let's put that aside for now. The CVE was seemingly (automatically?) raised on the basis of a single failing OSS Fuzz test yaml case, and that specific case now yields a SnakeYAML exception (about use of recursive keys, under default configuration) rather than the stack overflow which OSS Fuzz considers a denial of service. That OSS Fuzz issue is now considered resolved by their automated testing, so I think it seems reasonable to deem it 'fixed' from a CVE perspective which is the argument I've put forward to the NIST NVD. Whether a JVM-caught stack overflow is actually a denial of service seems a subject of reasonable debate, but maybe not so relevant to reducing the noise here.
It remains an open concern for users to continue using SnakeYAML to parse completely untrusted arbitrary input, and how far something like SnakeYAML should go to protect users/downstream libs from themselves (especially when in conflict with YAML specs), but that seems yet another different debate.
Comment From: chadlwilson
NVD is updated now after my submission yesterday: https://nvd.nist.gov/vuln/detail/CVE-2022-38752 I believe only OSSIndex is marking some of these more recent vulns incorrectly right now.
Comment From: OrangeDog
Unless I'm mistaken Boot 2.7.6 is still using SnakeYAML 1.30. Shouldn't this have been included?
Comment From: bclozel
@OrangeDog no we didn't upgrade on purpose, see #32221
Comment From: OrangeDog
@bclozel where in there exactly? https://github.com/spring-projects/spring-boot/issues/32221#issuecomment-1238030093 implies you were going to update to >=1.31
Comment From: snicoll
@OrangeDog I would expect you'd be acquainted with our third party upgrade policy by now. That comment is about being compatible at runtime, not upgrading to a new feature release of a dependency in a maintenance release of Spring Boot.
Comment From: OrangeDog
Clearly it's SnakeYAML's versioning policy I'm not familiar with. I thought 1.31 and 1.32 were bugfix releases.
Comment From: asomov
@OrangeDog there was no bug to fix in SnakeYAML - there was a false positive which becomes silent after minor code modification