[4.0.10] Please stop using SnakeYml 2.0

[hrstoyanov]

Environment Details

• Helidon Version: 4.0.10
• Helidon SE or Helidon MP: SE
• JDK version: 22.01

• OS: MacOS

Problem Description

Please stop using SnakeYml 2.0 in Helidon SE 4 - instead, switch to SnakeYml-Engine.

|    \--- io.helidon.config:helidon-config-yaml:4.0.10
|         +--- io.helidon.config:helidon-config:4.0.10 (*)
|         +--- io.helidon.common:helidon-common:4.0.10
|         \--- org.yaml:snakeyaml:2.0

SnakeYml requires java.desktop internal JDK module (via java.beans package dependency, it seems), which is quite inappropriate for server apps based on Helidon, especially if you want your Helidon container images to be small. Without including java.desktop module (via the jlink utility) in your container builds, one gets a nasty runtime surprise:

Exception in thread "main" java.lang.NoClassDefFoundError: java/beans/IntrospectionException
    at org.yaml.snakeyaml@2.0/org.yaml.snakeyaml.representer.BaseRepresenter.getPropertyUtils(BaseRepresenter.java:234)
    at org.yaml.snakeyaml@2.0/org.yaml.snakeyaml.Yaml.initDumperOptions(Yaml.java:119)
    at org.yaml.snakeyaml@2.0/org.yaml.snakeyaml.Yaml.<init>(Yaml.java:111)
    at org.yaml.snakeyaml@2.0/org.yaml.snakeyaml.Yaml.<init>(Yaml.java:101)
    at io.helidon.config.yaml@4.0.10/io.helidon.config.yaml.YamlConfigParser.toMap(YamlConfigParser.java:117)
    at io.helidon.config.yaml@4.0.10/io.helidon.config.yaml.YamlConfigParser.parse(YamlConfigParser.java:101)
    at io.helidon.config@4.0.10/io.helidon.config.spi.ConfigParser.parse(ConfigParser.java:91)
    at io.helidon.config@4.0.10/io.helidon.config.ConfigSourceRuntimeImpl$ParsableConfigSourceReloader.lambda$get$0(ConfigSourceRuntimeImpl.java:477)
    at java.base/java.util.Optional.map(Unknown Source)
    at io.helidon.config@4.0.10/io.helidon.config.ConfigSourceRuntimeImpl$ParsableConfigSourceReloader.get(ConfigSourceRuntimeImpl.java:460)
    at io.helidon.config@4.0.10/io.helidon.config.ConfigSourceRuntimeImpl$ParsableConfigSourceReloader.get(ConfigSourceRuntimeImpl.java:443)
    at java.base/java.util.Optional.orElseGet(Unknown Source)
    at io.helidon.config@4.0.10/io.helidon.config.ConfigSourceRuntimeImpl.initialLoad(ConfigSourceRuntimeImpl.java:218)
    at io.helidon.config@4.0.10/io.helidon.config.ConfigSourceRuntimeImpl.load(ConfigSourceRuntimeImpl.java:173)
    at io.helidon.config@4.0.10/io.helidon.config.ConfigSourcesRuntime.load(ConfigSourcesRuntime.java:153)
    at io.helidon.config@4.0.10/io.helidon.config.ProviderImpl.newConfig(ProviderImpl.java:90)
    at io.helidon.config@4.0.10/io.helidon.config.BuilderImpl.build(BuilderImpl.java:350)
    at io.helidon.config@4.0.10/io.helidon.config.BuilderImpl.build(BuilderImpl.java:53)
    at insbiz.webapp/insbiz.webapp.App.main(App.java:67)
Caused by: java.lang.ClassNotFoundException: java.beans.IntrospectionException
    at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(Unknown Source)
    at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(Unknown Source)
    at java.base/java.lang.ClassLoader.loadClass(Unknown Source)

[tomas-langer]

A bit of analysis:

• the good thing is that the engine does not have a package split
• the slightly worse thing is that we do need snake yaml with the full feature set for some of our features (such as OpenAPI), so we would end up with both on the classpath

Regarding CVEs reported against SnakeYAML (up to this point in time) - we have upgraded to latest version, we use safe constructor, we never use it to parse untrusted sources. As a result, we are not impacted by these "false positives" that are often triggered by tools.

So even though I understand this issue (to limit the dependency to the stuff that is really required), it would also actually increase the surface of possible attacks, as we would depend on both the full library and the engine. I am hoping that eventually the engine will be used as a base for the full version - if that happens, we would get rid of all the negative effects of applying this change.