dependency on jakarta.json 2.0.1 triggers CVE-2023-4043

[vwegert-adesso]

Version

5.5.0

What happened?

In a customer project, we use a library that in turn uses jena-shex and jena-arq both in version 5.5.0. The latter depends on org.glassfish jakarta.json version 2.0.1

jena/pom.xml

Line 67 in e325baa

<ver.jakarta.json>2.0.1</ver.jakarta.json>

This in turn contains https://github.com/jakartaee/jsonp-api/blob/2.0.1-RELEASE/impl/src/main/java/org/glassfish/json/JsonNumberImpl.java, which, according to a mandatory scanning tool, is affected by https://www.cve.org/CVERecord?id=CVE-2023-4043.

Would it be possible to upgrade to a more recent implementation, e.g. org.eclipse.parsson?
(This also affects version 5.6.0)

Relevant output and stacktrace

Are you interested in making a pull request?

None

[afs]

The dependency comes because of titanium-jsonld and it looks like it isn't used directly by Jena code.

It should be a matter of changing the top level POM and jena-arq if you'd like to give it a go.

What other providers are there?

[vwegert-adesso]

We're attempting to use Parsson as a replacement - I don't have any test results yet, but I wouldn't count too much on them anyway: Since jena-* is a dependency of a dependency, I am quite sure we don't cover all potential use cases in our tests.

[afs]

Jena is in a similar situation - it is only choosing a provider for the 3rd party titanium-jsonld to use, not running a JSON-LD test suite. It tests connectivity but the parsing of JSON-LD is done by titanium.

(What I don't understand is why the github security scan hasn't notified this situation.)

[rvesse]

(What I don't understand is why the github security scan hasn't notified this situation.)

Note that the CVE in question appears to relate to Eclipse Parsson not jakarta.json as the ticket title suggests. And the version numbers for Parsson stated in the CVE have no relation to the Jakarta JSON version numbers you are noting here. I guess maybe Parsson was forked from Jakarta JSON and the vulnerable code still exists in Jakarta JSON?

Security scanning tools vary in their accuracy and can suffer from both false positives and negatives. It would be useful to have the following information to investigate further:

• The mvn dependency:tree for your project showing the path to the affected dependency (to verify which dependency is actually affected)
• The security scanner results (ideally in a portable format like SARIF JSON)

As already noted usually the way downstream consumers of Jena resolve issues like this is to exclude the affected dependencies in their own pom.xml (or equivalent) and add explicit dependencies on the newer versions they prefer (assuming those newer versions are compatible)

[vwegert-adesso]

I guess maybe Parsson was forked from Jakarta JSON and the vulnerable code still exists in Jakarta JSON?

That is my current working hypothesis as well.

Security scanning tools vary in their accuracy and can suffer from both false positives and negatives. It would be useful to have the following information to investigate further:

We're currently checking what information we can provide.

As already noted usually the way downstream consumers of Jena resolve issues like this is to exclude the affected dependencies in their own pom.xml (or equivalent) and add explicit dependencies on the newer versions they prefer (assuming those newer versions are compatible)

This is our current approach as well, but I'd say it would be preferable if these kinds of workaround would not be needed in the first place.

[rvesse]

This is our current approach as well, but I'd say it would be preferable if these kinds of workaround would not be needed in the first place.

Sure but like many open source projects Jena is entirely volunteer driven and has a relatively slow release cadence (~3 months) unless there's a critical security issue we need to address sooner. This is part of the trade off to choosing to use open source, sometimes you have to own the workarounds and fixes until those can filter back upstream.

If there's a newer dependency version for us to take then that's relatively simple to do, but if there isn't, as appears to be the case here, and we'd have to swap in a different dependency that takes time and effort to understand the implications, especially when it isn't a direct dependency of Jena but coming via an upstream library - https://github.com/filip26/titanium-json-ld - as already noted. You may also want to consider filing an issue there but that project is effectively a solo volunteer effort so I wouldn't expect the resolution there to be particularly any faster.

[rvesse]

FYI looks like titanium-json-ld are already considering what JSON library to move forward to for their eventual 2.x release - filip26/titanium-json-ld#416 - so may be worth adding to that discussion

[filip26]

@vwegert-adesso

In a customer project, we use a library that in turn uses jena-shex and jena-arq both in version 5.5.0. The latter depends on org.glassfish jakarta.json version 2.0

This is a recurring situation - companies rely on open-source software without contributing back to its maintenance, and then request “quick free fixes” when something doesn’t work as expected.

Please remember that open-source maintainers contribute their time voluntarily. If this product is critical for your organization, consider sponsoring the project.

[afs]

We're attempting to use Parsson as a replacement - I don't have any test results yet, but I wouldn't count too much on them anyway:

and earlier:

This is our current approach as well, but I'd say it would be preferable if these kinds of workaround would not be needed in the first place.

@vwegert-adesso Are you saying that Parsson does work for you? Is the test coverage on a significant number of JSON-LD files?

it would be preferable if these kinds of workaround would not be needed in the first place.

Yes, but.

We do not know your environment. You have said you use Jena via another library - which one? - so the dependency setup is not simple.

What is important for Jena is to fix the problem for everyone in one go. Information from users is helpful for that.

[vwegert-adesso]

I was not aware that jakarta.json was pulled in by Titanium JSON-LD - thanks for the references!

You have said you use Jena via another library - which one? - so the dependency setup is not simple.

The library we actually use is HAPI FHIR, in this case the hapi-fhir-structures-r4 project - at least that is the one the scanner is displaying.

https://github.com/hapifhir/hapi-fhir/blob/c8002daec051b097384108340817e0a2ccc5b6b2/hapi-fhir-structures-r4/pom.xml#L122-L125

Versions in parent pom:

https://github.com/hapifhir/hapi-fhir/blob/c8002daec051b097384108340817e0a2ccc5b6b2/pom.xml#L1039

https://github.com/hapifhir/hapi-fhir/blob/c8002daec051b097384108340817e0a2ccc5b6b2/pom.xml#L1670-L1690

I'm still working on the export data you requested.

This is a recurring situation - companies rely on open-source software without contributing back to its maintenance, and then request “quick free fixes” when something doesn’t work as expected.

Just to make it unambiguously clear: I am NOT "requesting" a "quick fix". We have a working solution and could just ignore the issue - but I'd like to try and find a permanent solution that benefits everyone. If that takes time, so be it.

[afs]

@vwegert-adesso - any news?

Removing "bug" because this is due to a dependency, not a thing to fix in Jena at the moment.