snakeyaml 1.32

[pjfanning]

Another release - maybe another CVE - unclear from release notes

https://bitbucket.org/snakeyaml/snakeyaml/wiki/Changes

https://bitbucket.org/snakeyaml/snakeyaml/issues/547/restrict-the-size-of-incoming-data

[cowtowncoder]

Thanks!

[pjfanning]

@cowtowncoder would it be ok to enable dependabot at least for security related dependency updates? I have enough access to do this but want to run it by you first.

[cowtowncoder]

@pjfanning I have had pretty bad experiences with Dependabot in general (I think it's PRs are often ill-advised to say the least). However -- this might be one of those cases where it could be useful as sort of watchdog, even if we didn't use PRs it provides.

So +1 for experimentation. We can get rid of it should there be lots of noise.

[yawkat]

you could also look at renovate, it's what we use with the micronaut repos.

[cowtowncoder]

yes that seems to be the other commonly used tool. I have no strong opinions.
@yawkat do you know what are the main differences between 2?

[yawkat]

I like the option to manually trigger PRs, instead of tons being created automatically. But I only work on it on the user side, so I don't know if there are other big advantages.

[cowtowncoder]

That is good, I think. But I guess part of it comes down to trade-offs b/w push (get notified ASAP on new versions) and pull (check every now and then, possibly on daily/weekly builds).

[mnonnenmacher]

@cowtowncoder @pjfanning It looks like there is no way to override the default limit of 3MB introduced in SnakeYAML 1.32, so Jackson 2.14 (or 2.13.5) could not parse YAML files larger than 3MB anymore. Is this correct?

[pjfanning]

Thanks @mnonnenmacher - no released version of jackson-dataformat-yaml uses snakeyaml 1.32 yet (unless a user overrides the dependency version themselves). I will raise a new issue for the limit issue.

[cowtowncoder]

@mnonnenmacher Yes and no: if there is such a limit -- and I don't necessarily doubt that what with the latest torrent of CVEs being filed -- then with the default versions this limit would apply.

But it is still possible to override version of SnakeYAML to include; Jackson does not require particularly recent version, and use of 1.31 for example is perfectly fine.

The problem we at Jackson team face is this: there is at least one new CVE filed against 1.31, and many users will get reports by security tools that claim them they are immediately vulnerable. Said users will often demand later version; hence default of 1.32 is likely the most popular choice.
Except, of course, if and when someone then hits this new limit.

Worse: assuming there will be a new setting in, say, 1.33, to adjust the limit, Jackson cannot easily use this configuration facility without then preventing use of anything BUT 1.33.
Of course there are ways around that (bit of dynamic access with error handling) but it gets tricky quite soon; and on some platforms (Android?) there can also be warnings for dynamic cases that look like errors.

[mnonnenmacher]

@pjfanning @cowtowncoder Thanks for the clarification.