Unable to open jar file while scanning a directory
Muskan-0618 opened this issue · comments
Hi,
We are trying to scan a directory using the latest version of dependency check and we are getting multiple warnings, like,
[WARN] Unable to open jar file 'guava-33.0.0-jre.jar'. .
This warning is there multiple times for many of the jars and this results in multiple CVEs being missed in the report.
On scanning the jars individually, we are getting the scan reports and not getting any warning.
Could you please help us out in finding out the possible reason for these warnings?
Enable the debug logging on your scan and in the log you should be able to find the full details on the IOException
This is the debug logs that we got for the same issue:-
WARN - Unable to open jar file 'Unable to open jar file 'guava-33.0.0-jre.jar'.'
2024-02-23 17:13:02,067 org.owasp.dependencycheck.analyzer.JarAnalyzer:1186
DEBUG -
java.util.zip.ZipException: zip file is empty
at java.base/java.util.zip.ZipFile$Source.zerror(ZipFile.java:1781)
at java.base/java.util.zip.ZipFile$Source.findEND(ZipFile.java:1562)
at java.base/java.util.zip.ZipFile$Source.initCEN(ZipFile.java:1657)
at java.base/java.util.zip.ZipFile$Source.(ZipFile.java:1495)
at java.base/java.util.zip.ZipFile$Source.get(ZipFile.java:1458)
at java.base/java.util.zip.ZipFile$CleanableResource.(ZipFile.java:724)
at java.base/java.util.zip.ZipFile.(ZipFile.java:251)
at java.base/java.util.zip.ZipFile.(ZipFile.java:180)
at java.base/java.util.jar.JarFile.(JarFile.java:345)
at java.base/java.util.jar.JarFile.(JarFile.java:316)
at java.base/java.util.jar.JarFile.(JarFile.java:269)
at org.owasp.dependencycheck.analyzer.JarAnalyzer.collectClassNames(JarAnalyzer.java:1173)
at org.owasp.dependencycheck.analyzer.JarAnalyzer.analyzeDependency(JarAnalyzer.java:308)
at org.owasp.dependencycheck.analyzer.AbstractAnalyzer.analyze(AbstractAnalyzer.java:131)
at org.owasp.dependencycheck.AnalysisTask.call(AnalysisTask.java:88)
at org.owasp.dependencycheck.AnalysisTask.call(AnalysisTask.java:37)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
at java.base/java.lang.Thread.run(Thread.java:1583)
Sometimes these jars are getting scanned and sometimes we are getting these warnings.
java.util.zip.ZipException: zip file is empty
looks like somehow your infra is resulting in an empty jar file for the guava library
But I the jar file is not empty when I unzipped it manually
Also, this is not a consistent problem. The jars for which we the scanner is giving this warning, are getting scanned in some of the scans.
Hi @aikebah and @jeremylong
There are multiple problems for which we are seeking a solution. I will start with how we are using dependency check. We have a Jenkins job set up which we use to trigger the scanning for .parcel.tar.gz format zipped files using dependency check. We are using the CLI command to trigger the dependency check scans.
The issues that we are facing are:-
1. Unable to open jar files:- This warning appears multiple times for many of the jars. When scanning the jars individually, we receive the scan reports without any warning. As I mentioned in my previous comment, the debug logs indicate ‘java.util.zip.ZipException: zip file is empty,’ but upon manual inspection, the zip file is not empty.
2. Inconsistency in the scanning of dependencies:- There are dependencies that are inconsistently identified and scanned by the tool. Sometimes, these dependencies are recognized during the scanning process, while other times, the tool fails to identify them. For example, ‘jruby-complete-9.2.13.0.jar’ has many dependencies, including ‘snakeyaml:1.26.’ However, it often occurs that the ‘snakeyaml:1.26’ jar is absent from the report. Upon rescanning the file, it reappears in the report. The configurations remain identical across all scans having inconsistencies, and it is noted that there is no evident pattern in the identification of dependencies.
3. Many times, not all the jars originating from another jar are included in the dependency check report. For instance, in the case of ‘jruby-complete-9.2.13.0.jar,’ ‘jruby-complete-9.2.13.0.jar’ shaded: ‘org.jruby:jruby-core:9.2.13.0’ is listed in the report along with some other jars from the same library. However, ‘jruby-complete-9.2.13.0.jar: snakeyaml-1.26.jar’ is not present in the report. But this thing happens while scanning the complete zipped parcel and not the individual jar.
These are the issues we are currently facing and we need your help to resolve them. Could you please provide some insights into the possible reasons for these issues and suggest actions we can take from our end to address them?
We would need sample projects that demonstrate this behavior. Additionally, I recommend switching to the maven or gradle plugin and not rely on the CLI.
Hi @jeremylong ,
We tried the maven plugin to scan our project and the number of CVEs increased by 230% and many of them are false positives.