Replacing jnr-unixsocket with Junixsocket

[usertree]

Jetty version 9.4.46 Java version 8 Question The JDK cannot be upgraded due to historical reasons, but the jnr-unixsocket has some critical vulnerabilities. How do I replace jnr-unixsocket with junixsocket? Is there a sample guide?

[gregw]

Jetty-10 & jetty-11 are based on the JVM unix socket implementation (as they can use latest JVM). JVM unix domain socket support is available on java8, so we cannot backport that.

By junixsocket, do you mean: https://kohlschutter.github.io/junixsocket/ ? If that project supports selectable channel API, then the work to port to it should not be significant. However, Jetty-9 is now at end of community support, so we will not be enhancing with such ports unless we have a commercial support client that will sponsor the work.

[usertree]

Junixsocket supports selectable channels. Therefore, can jetty9.4.* theoretically support switching from jnr-unixsocket to jnr-unixsocket? Does the Unix domain client only need to extend these two classes?

[joakime]

To repeat what @gregw pointed out ...

Jetty 9.4.x is now at End of Community Support and is scheduled to be EOL in 6 months.

• #7958

[kohlschuetter]

Since there's probably at least another person who thought about adding junixsocket to jetty but then gave up: I'm now adding jetty support to junixsocket (via the "junixsocket-jetty" artifact).

The latest code (2.5.1-SNAPSHOT) now supports both a server connector (jetty >= 9.4.12) and a client connector (jetty >= 10.0.8). Please give it a try and let me know if that works for you.

See discussion in https://github.com/kohlschutter/junixsocket/issues/108

[gregw]

@kohlschuetter Can you give me a bit of background on the junixsocket project, specificially with regards to it's intended usage post jvm 16 with unix domain socket support? Is it intended to be a viable alternative going forward or just something to provide support for users that cannot upgrade JVMs?

I ask, as if it is something that might be useful for some users against newer versions of Jetty, then it will affect how we might link to it (in code and/or documentation and/or in this issue). In short, please feel free to give your elevator pitch for the project here.

[kohlschuetter]

@gregw Thank you! junixsocket will not become obsolete with Java 16's introduction of UnixDomainSocketAddress, and the plan is to keep it growing.

junixsocket provides

1. a much more comprehensive implementation of unix domain sockets, including support for peer authentication via socket credentials, file descriptor passing between processes, socketpair, the abstract namespace on Linux, etc.
2. a better integration with the existing Java Socket API (not just SocketChannel as with JEP 380)
3. a better integration with existing apps that rely on InetAddress/InetSocketAddress (for example, junixsocket enables Java RMI via AF_UNIX)

Moreover, some time ago I realized that junixsocket can cover much more than just unix domain sockets. junixsocket essentially enables Java apps to support all sorts of things that use the Unix/BSD socket API:

Since version 2.5.0, junixsocket adds support for other address families, starting with AF_TIPC (which means you can run jetty over TIPC sockets if you want to; it's a pretty cool protocol).

Adding support for AF_VSOCK shouldn't be too difficult either — this would enable tight VM environments (Linux or maybe even unikernels) that can serve content without a TCP/IP stack.

So yeah, junixsocket won't be just a stop-gap solution, even though it's already pretty compelling for anyone running Java 8 or above. It's actually a viable alternative and growing rapidly in scope and depth.

[gregw]

@sbordet @lorban we should discuss this.

[github-actions[bot]]

This issue has been automatically marked as stale because it has been a full year without activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions[bot]]

This issue has been closed due to it having no activity.