Upgrade / replace Log4j Library

[misilot]

We are getting reports from our security folks that they are detecting log4j 1.2.17

Would this be able to be replaced with maybe slf4j-reload4j?

[kshepherd]

@misilot we did something similar with DSpace 6.x, since other constraints meant we could not upgrade log4j itself. However, in recent versions of DSpace application we are able to use log4j >= 2.23.1 and avoid having to use reload4j -- is that something we could do here too, or do we need to support old java versions, and other dependencies?

(or branch off into a legacy branch, with reload4j drop in, and a main branch with modern jdk requirements and other dependency version bumps including log4j)

[misilot]

I'd be happy with either way! I just don't have a great Java background, so was looking for a drop in replacement to make our security folks happy. (Part of it was my build layers w/ Docker that I was able to fix as well)

[jameswsullivan]

I believe I have come up with a solution for this issue, I've tested in our instance and it's working as intended.
I also managed to resolve all the Jetty related vulnerabilities that shipped with the latest handle software, which I'm thinking about contacting them to see if they can make a newer minor release.

Please see my gist and code changes:

• https://gist.github.com/jameswsullivan/a7335b1d1d1021a3f3c8f5e207686d72
• https://github.com/jameswsullivan/Remote-Handle-Resolver/tree/v1.1-unofficial
• https://github.com/jameswsullivan/Handle.Net-Software/tree/handle-9.3.3-unofficial
  • https://github.com/jameswsullivan/Handle.Net-Software/blob/handle-9.3.3-unofficial/changes.md

This is my test build that has been running for a few days: https://github.com/jameswsullivan/docker-dspace-handle-server/tree/mitigate-vulns

@tdonohue

[tdonohue]

@jameswsullivan : I'm waiting on responses from others, as I'll admit, I don't have experience with this Remote-Handle-Resolver and I'm not sure who all is using it anymore. @kshepherd or @misilot may have thoughts as they seem to be the last ones on this ticket.

(As a sidenote: if this Remote-Handle-Resolver is still in use by several institutions, maybe it'd be better to consider migrating it into the main codebase since it appears to be just one class? It seems like it's not getting much maintenance over in this separate project.)

[jameswsullivan]

@tdonohue I agree . I use this method rather than DSpace's built-in one because we have two DSpace instances, having a standalone handle server container to resolve to multiple dspace instances is easier so that DSpace updates won't affect the handle deployment.

Since it's just one file and ultimately just a jar artifact (plus a log4j2.xml and a couple other configs files from the wiki) to add to the handle server installation, there might be a way for DSpace's main code to produce such a module/jar and we can copy it out for use? Searching DSpace's code I saw this, DSpace's built-in resolver is baked into the code rather than using a separate plugin I guess (but I'm no expert regarding the main DSpace code).

[kshepherd]

I don't use this resolver myself but I agree it'd probaby be good to bring this into the main codebase eventually, it supports some use cases that the built-in DSpace one doesn't.

@jameswsullivan thanks for the fix - would you be able to open a PR to make it a bit easier to analyse the full set of changes?

[jameswsullivan]

@kshepherd Sure, I planned to while I was making the changes, but since it also involved changes with using log4j2.xml/DSpace documentation, adding log4j2 to handle software, etc., I wanted to ask first and see what you all think. I'll open a PR soon.

[misilot]

@jameswsullivan we use this currently (in a containerized version). I actually plan on augmenting how we use this with a intermediate API that will talk to DSpace's handle check endpoint, but have our intermediate API check to see if we have moved the handle from a list and if it we have return the new non-dspace url. So I'm excited for these updates to make our security folks happy!

[pnbecker]

We use the remote handle resolver.

I would be happy to integrate it into DSpace/main. The reason we created it here was that it needs to build its own jar file that then has to be installed with the handle server together. The DSpace main branch also has code to provide the necessary rest endpoint for the remote handle resolver.

@tdonohue would it be acceptable to put such a jar file into /dspace/lib and to document where to find it? Then it would always be build together with DSpace. If we want to separate it from the jars we load together with DSpace, it could also be placed into a new directory like /dspace/usr/lib or /dspace/connectors or whatever we think is appropriate. I don't see a technical reason for such a separation, just want to point out the options.

[tdonohue]

@pnbecker : Since this appears to be a single Java Class (with a config file), I'm not sure why we don't simply move it over to the dspace-api source code and document how to enable it if you want to use it. Obviously, though, by default it must be disabled.

I'll admit though that I don't know if it's that simple or not. But, as this is just a single Java class, I'm not sure why we are maintaining it separately -- that separate maintenance means it doesn't get upgrades to dependencies in the same way that we are upgrading DSpace backend dependencies regularly.

[jameswsullivan]

@tdonohue @pnbecker Correct me if I'm wrong, as how I understand it, I think this is not really a DSpace's built-in component or part of DSpace API per se, DSpace's built-in handle resolver already has its own implementation. This is a separate plugin that you build a jar and drop into a separate/standalone handle server installation, for the standalone handle server to be able to resolve to one or more DSpace instances, while DSpace's own built-in handle implementation can only resolve to its own DSpace instance. If there are multiple DSpace installations, each instance would run its own "handle server" within/along side the DSpace installation, as a separate "process" (which you start on the same server with [dspace]/bin/start-handle-server . So it's probably not a matter of enabled/disabled in this case, but including this plugin as part of the DSpace build, to produce a jar file and place it under somewhere like /dspace/lib , /dspace/plugin for others to grab the jar for use.

As a sidenote, I also contacted the handle software support asking about updating the Jetty version and dropping the log4j stuff into their lib.