JsonArrayFixingInputStream produces broken output on certain repositories

Describe the bug JsonArrayFixingInputStream produces broken output on certain repositories.

Version of dependency-check used The problem occurs using version 6.1.3 of the cli. The older release 6.1.2 is working.

Log file

2021-03-26 18:19:35,948 org.owasp.dependencycheck.App:208
ERROR - Unexpected exit code from go process; exit code: 141
2021-03-26 18:19:35,949 org.owasp.dependencycheck.App:209
DEBUG - unexpected error
org.owasp.dependencycheck.analyzer.exception.AnalysisException: Unexpected exit code from go process; exit code: 141
        at org.owasp.dependencycheck.analyzer.GolangModAnalyzer.analyzeDependency(GolangModAnalyzer.java:295)
        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:264)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
        at java.base/java.lang.Thread.run(Thread.java:832)
        Suppressed: org.owasp.dependencycheck.analyzer.exception.AnalysisException: Error parsing stream
                at org.owasp.dependencycheck.data.golang.GoModJsonParser.process(GoModJsonParser.java:86)
                at org.owasp.dependencycheck.processing.GoModProcessor.run(GoModProcessor.java:62)
                ... 1 common frames omitted
        Caused by: javax.json.stream.JsonParsingException: Invalid token=COLON at (line no=979, column no=8, offset=36995). Expected tokens are: [COMMA]
                at org.glassfish.json.JsonParserImpl.parsingException(JsonParserImpl.java:450)
                at org.glassfish.json.JsonParserImpl.access$1100(JsonParserImpl.java:79)
                at org.glassfish.json.JsonParserImpl$ArrayContext.getNextEvent(JsonParserImpl.java:557)
                at org.glassfish.json.JsonParserImpl.next(JsonParserImpl.java:376)
                at org.glassfish.json.JsonParserImpl.getArray(JsonParserImpl.java:324)
                at org.glassfish.json.JsonParserImpl.getArray(JsonParserImpl.java:164)
                at org.glassfish.json.JsonReaderImpl.readArray(JsonReaderImpl.java:129)
                at org.owasp.dependencycheck.data.golang.GoModJsonParser.process(GoModJsonParser.java:71)
                ... 2 common frames omitted

To Reproduce Steps to reproduce the behavior:

1. dependency-check -l scan.log --scan go.mod
2. See error in log

Expected behavior Successful execution.

Additional context As a quick fix I increased the buffer size and I’m able to execute the scanner succesfully (based on git commit b1bbc4469):

diff --git a/utils/src/main/java/org/owasp/dependencycheck/utils/JsonArrayFixingInputStream.java b/utils/src/main/java/org/owasp/dependencycheck/utils/JsonArrayFixingInputStream.java
index c0b253a69..b2a367a48 100644
--- a/utils/src/main/java/org/owasp/dependencycheck/utils/JsonArrayFixingInputStream.java
+++ b/utils/src/main/java/org/owasp/dependencycheck/utils/JsonArrayFixingInputStream.java
@@ -49,7 +49,7 @@ public class JsonArrayFixingInputStream extends InputStream {
     /**
      * The buffer length.
      */
-    private static final int BUFFER_SIZE = 2048;
+    private static final int BUFFER_SIZE = 8192;
     /**
      * The input stream to be filtered.
      */

[jeremylong]

With #3599 the primary bug has been resolved. In addition we have improved the error reporting so that if an error occurs analyzing a go.mod in the vendor directory you will be able to tell (i.e. we are better about including the file path in the error message). I’m still debating whether or not we should completely skip any go.mod in the vendor directory…

[davidandradeduarte]

The repository I’m testing only has one go.mod with about 18 dependencies, so I don’t think it has something to do with vendor folders or multiple go.mod files (at least in my case - it can be a different issue).

Tried

dependency-check -o . -s ./go.mod --enableExperimental 

and errors with

Unexpected exit code from go process; exit code: 141
exception: org.owasp.dependencycheck.analyzer.exception.AnalysisException: Unexpected exit code from go process; exit code: 141
org.owasp.dependencycheck.analyzer.GolangModAnalyzer.analyzeDependency(GolangModAnalyzer.java:297)
org.owasp.dependencycheck.analyzer.AbstractAnalyzer.analyze(AbstractAnalyzer.java:131)
org.owasp.dependencycheck.AnalysisTask.call(AnalysisTask.java:88)
org.owasp.dependencycheck.AnalysisTask.call(AnalysisTask.java:37)
java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
java.base/java.lang.Thread.run(Thread.java:831)

I’m running 6.2.2 (latest by the time of writing).