Jetty 9 is EOL

[cortlepp]

Jetty 9 is EOL and is no longer being maintained. If I see this correctly it is only being used in the htmlunit-websocket-client in the class org.htmlunit.websocket.JettyWebSocketAdapter. Is there anything concretely blocking an update to Jetty 12 (the latest currently maintained version of Jetty)?

References:

• the commit that introduced htmlunit-websocket-client
• a current CVE in Jetty 9 that will not be resolved due to this version being EOL

[rbri]

Is there anything concretely blocking an update to Jetty 12

HtmlUnit is at JDK8

[niloc132]

Note also that HtmlUnit is only using jetty's websocket client, so most CVEs/etc that apply to Jetty 9 will not impact HtmlUnit.

[cortlepp]

Is there anything concretely blocking an update to Jetty 12

HtmlUnit is at JDK8

How do you intend to move forward in this regard? I understand that some people may still be stuck on JDK8, but the world is moving on and it will only become increasingly difficult to maintain the library. So is there a plan to migrate to a more recent JDK, or how do you want to handle "bitrot" issues like this one, now and in the future?

[cortlepp]

Note also that HtmlUnit is only using jetty's websocket client, so most CVEs/etc that apply to Jetty 9 will not impact HtmlUnit.

Thanks for the hint, but I think it would still be better to tackle the root cause. The vulnerability I cited above is in a URI implementation, it's anybody's best guess whether this affects the parts of the code we are using. Apart from that, a new vulnerability (in code that we are relying on) could pop up anytime, and when we are relying on EOL libs there is nothing we can do except upgrade to a supported version.

[cortlepp]

I just now noticed (thanks to the PR comment by @niloc132) that the real Issue is in htmlunit-websocket-client, and that this is not a submodule of this repo. Would you be open to publishing a new major version of this websocket client if I provided a PR for this (which would then require JDK 17 / Jetty 12) as an official maven artifact that people could then use as a drop-in replacement? I.e. the default could even stay at JDK 8, if that is important.