Vulnerable dependencies

[jukuisma]

Hey,

we're enabling Xray scans for all our RPMs and it doesn't seem to like some jhove dependencies:

https://nvd.nist.gov/vuln/detail/CVE-2023-2976
https://nvd.nist.gov/vuln/detail/CVE-2024-25710
https://nvd.nist.gov/vuln/detail/CVE-2024-26308
https://nvd.nist.gov/vuln/detail/CVE-2020-8908

I'm not super familiar with java packaging, but the above components do seem to be used as some external dependencies:

vagrant@almalinux ~/github/jhove/jhove-latest (integration)
$ strings resources/packs/pack-JHOVE\ External\ Modules | grep guava
META-INF/maven/com.google.guava/PK
META-INF/maven/com.google.guava/guava/PK
META-INF/maven/com.google.guava/failureaccess/PK
META-INF/maven/com.google.guava/listenablefuture/PK
META-INF/maven/com.google.guava/guava/pom.properties%
META-INF/maven/com.google.guava/guava/pom.xml
META-INF/maven/com.google.guava/failureaccess/pom.properties
META-INF/maven/com.google.guava/failureaccess/pom.xml
META-INF/maven/com.google.guava/listenablefuture/pom.xml
META-INF/maven/com.google.guava/listenablefuture/pom.properties%
META-INF/maven/com.google.guava/PK
META-INF/maven/com.google.guava/guava/PK
META-INF/maven/com.google.guava/failureaccess/PK
META-INF/maven/com.google.guava/listenablefuture/PK
META-INF/maven/com.google.guava/guava/pom.propertiesPK
META-INF/maven/com.google.guava/guava/pom.xmlPK
META-INF/maven/com.google.guava/failureaccess/pom.propertiesPK
META-INF/maven/com.google.guava/failureaccess/pom.xmlPK
META-INF/maven/com.google.guava/listenablefuture/pom.xmlPK
META-INF/maven/com.google.guava/listenablefuture/pom.propertiesPK

vagrant@almalinux ~/github/jhove/jhove-latest (integration)
$ strings resources/packs/pack-JHOVE\ External\ Modules | grep commons-compress
META-INF/maven/org.apache.commons/commons-compress/PK
META-INF/maven/org.apache.commons/commons-compress/pom.xml
META-INF/maven/org.apache.commons/commons-compress/pom.propertiesK,*
META-INF/maven/org.apache.commons/commons-compress/PK
META-INF/maven/org.apache.commons/commons-compress/pom.xmlPK
META-INF/maven/org.apache.commons/commons-compress/pom.propertiesPK

Can those be updated to the fixed versions?

Cheers, Juho

[carlwilson]

Hi @jukuisma, and thanks for reporting this. You are correct that the commons-compress and guava dependencies are packaged in the jhove-ext-modules jar, and by extension, with JHOVE. These aren't direct dependencies, which are declared in the jhove-ext-modules project pom. They're brought in by JHOVE's epub checking module (one of the external modules). JHOVE currently uses version 5.1 of epubcheck. epubcheck in turn includes modules: commons-compress v1.21 and guava v31.1-jre.

The good news is that guava is updated to v32.0.0-jre in version 5.2 of epubcheck. Commons compress isn't updated as yet, I'll look to raise an issue and PR for that. There is already a PR that updates the epubcheck dependency, but it came too late for the 1.34 release.

The short version is we will try to address this for a v1.34.1 patch in the not too distant future.

[carlwilson]

Hi @jukuisma, since 1.34 was a release candidate, we've incorporated the epubchecker update into 1.32.0, released today. That means that CVE-2023-2976 and CVE-2020-8908 are now addressed. The two others remain. I tried naively updating the commons-compress depency in epubchecker myself but it broke a bunch of unit tests and I left it there. Not completely fixed, but getting there and may require a separate issue as we can't address this ourselves.

[jukuisma]

Great news!

update into 1.32.0

I take it you mean 1.34.0? And it seems to be missing the non-RC xplt installer, but should probably be synced there on some delay? https://software.openpreservation.org/rel/jhove/1.34

Not completely fixed, but getting there and may require a separate issue as we can't address this ourselves.

What do you think about reporting upstream and which one of us should do it? We can always explicitly allow CVEs we've evaluated as benign in our pipelines, but I'd much rather try to get them fixed than start evaluating which ones to allow.

[carlwilson]

Hi @jukuisma the link for 1.34 is https://software.openpreservation.org/rel/jhove/1.34/jhove-installer-1.34.0.jar, we dropped the xplt as it was really a historic artefact.

I think reporting upstream is an excellent idea. If you would like to do that please and let me know here. I will the support your issue and look to see if I can provide a fix. Might be better if two of us were involved. I'll keep this open until we are there.

[jukuisma]

Hi @jukuisma the link for 1.34 is https://software.openpreservation.org/rel/jhove/1.34/jhove-installer-1.34.0.jar, we dropped the xplt as it was really a historic artefact.

Our RPM build seems to still use that, but we'll have a look at ditching it before upgrading to 1.34:

java -jar jhove-xplt-installer-%{version}.jar auto-install.xml

I don't imagine that being a huge hassle.

I think reporting upstream is an excellent idea. If you would like to do that please and let me know here. I will the support your issue and look to see if I can provide a fix. Might be better if two of us were involved. I'll keep this open until we are there.

My vacation starts next week and I'm quite busy this week. I'll be totally unreachable for the next few weeks, but I can report it once I'm back.

[jukuisma]

@carlwilson fixes should be available @ https://github.com/w3c/epubcheck/releases/tag/v5.3.0

[carlwilson]

Thanks for this @jukuisma, I'll look to get this updated as soon as possible, Unfortunately, I'm away until the middle of October. We will get a JHOVE release out before the end of the year.

[jukuisma]

ACK, no hurry, we'll update once it's out. I did also test the new installer with the exact same old auto-install.xml and it seems to work as is.

[karenhanson]

@carlwilson Tried upgrading to 5.3.0 but ran into an issue: parseEpubWithWrongExtensionTest() now fails because the non-.epub extension message changed severity from INFO to USAGE. (commit)

I see that USAGE messages are suppressed by default. The spec explains the difference and gives a list of messages:
https://www.w3.org/publishing/epubcheck/docs/messages#severity-levels
To my eye, USAGE seems similar to INFO in JHOVE.

My question: should the JHOVE EPUB module map USAGE to INFO for reporting purposes? Or should USAGE messages be dropped as they are by default in EPUBCheck... and as (I now discover) they were in previous versions of JHOVE? In that case I would remove the file extension test.

If mapped to INFO, more messages will appear than previously - so in that case, should there be a configurable parameter to mute USAGE? Or is it best to keep the universal INFO level and include both USAGE + INFO when enabled?

My preference is to map these messaages to INFO and treat the two categories as one rather than add extra log levels or supress messages, but I'd like another opinion before editing the code. Thanks!