Update SnakeYAML-Engine to 3.0.1

[headius]

There are two CVEs in Guava, which is a test-scoped dependency of this library. Guava is not shipped with the library so these CVEs do not affect users, but the dependency may trigger security tools. We update to avoid this false positive.

https://www.cve.org/CVERecord?id=CVE-2023-2976

https://www.cve.org/CVERecord?id=CVE-2020-8908

Fixes #780

[chadlwilson]

snakeyaml-engine 3.x requires Java 11. Was it intentional to drop support for Java 8?

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

The tests here don't run across java versions sufficiently to validate these types of things; they just use either the actions runner default JDK or the latest default on the given Ubuntu version.

[chadlwilson]

If this was unintentional, and you're open to it, im happy to either submit a PR to

1. run tests under java 8 and a min supported JRuby version (not solely jruby-head)
2. OR to use deterministic supported java versions for each JRuby version under test
3. OR to just use a standard maven plugin to check the jar dependencies are java 8 compatible via the existing Mavenfile

#1 may be more maintainable & understandable for non Java experts in the team (and also validate the code under 8 via tests), but does add more to the build.

For @hsbt benefit, JRuby 9.3 (EOL but still supported by this gem via its constraints) and 9.4 (nearing EOL) both support Java 8. JRuby 10.0+ supports Java 21 minimum.

[headius]

@chadlwilson I did not realize that SnakeYAML had dropped Java 8. That's not a problem for JRuby 10+ but obviously is for JRuby 9.4 (not quite yet EOL).

The only way to do this same patch in a Java-8-friendly way would be to get @asomov to do another 2.x release of SnakeYAML-Engine with the updated Guava dependency.

Perhaps we should just deal with users still using JRuby 9.4 on Java 8 individually, and they can either pin to the older Psych or we can work with all parties involved to backport patches.

[chadlwilson]

As I mentioned at #780 (comment) given it's a test-scoped dependency, I don't think it was really necessary to do anything here - test scoped dependencies won't trigger any security tool that I am aware of. So there doesn't seem a good reason to do another 2.x release for that.

If you want to move forward rather than roll back, I don't think we should drop support for even an EOL Java version in a psych patch release - could use a feature release at least? If the next plan is 5.4.0 that is probably fine; not sure how versioning is decided here.

[asomov]

Sorry, I do not quite catch the issue. If the only problem is an ancient version of Guava in tests - please give me the proper version. In the coming SnakeYAML 3.1 the version will be updated.

[headius]

@chadlwilson

I don't think we should drop support for even an EOL Java version in a psych patch release

You're probably right, and since Ruby folks generally don't set specific versions for stdlib gems, it's only a matter of time before we break someone's JRuby 9.4 app. I'll revert this and perhaps we just ignore it for now.

@asomov A user reported a false-ish positive security issue due to versions of 2.x that used an exploitable version of Guava during testing. You've already done the necessary update in 3.x, but 3.x only supports Java 11+ and JRuby 9.4 still supports Java 8.

By upgrading Psych to SnakeYAML-Engine 3.x, users will no longer be able to use it with JRuby 9.4 on Java 8.

The fix would be for you to release one more 2.x that updates Guava, but don't bother with that right now. JRuby 9.4 is supposed to be EOL in the next month, and this is not really a real security issue. We'll just keep using 2.x in Psych for now and figure out how to move forward from here.