Dependencycheck: Golang Mod Analyzer fails in 6.0.2

Created on 27 Sep 2020  路  2Comments  路  Source: jeremylong/DependencyCheck

Describe the bug
Golang Mod Analyzer fails in 6.0.2 can't handle vendordirectories

Version of dependency-check used
Dependency-Check Core version 6.0.2
go version go1.14.9 darwin/amd64

Log file
GO111MODULE=on:

[INFO] Golang Mod Analyzer is enabled.
[INFO] Launching: [go, list, -json, -m, all] from /foo/bar
[WARN] Warnings from go go list -m: can't compute 'all' using the vendor directory  (Use -mod=mod or -mod=readonly to bypass.)
[WARN] An error occurred while analyzing '/foo/bar/go.mod' (Golang Mod Analyzer).

GO111MODULE=off:

2020-09-28 10:10:11,636 org.owasp.dependencycheck.App:208
ERROR - Error reading stream
2020-09-28 10:10:11,636 org.owasp.dependencycheck.App:209
DEBUG - unexpected error
org.owasp.dependencycheck.analyzer.exception.AnalysisException: Error reading stream
        at org.owasp.dependencycheck.data.golang.GoModJsonParser.process(GoModJsonParser.java:85)
        at org.owasp.dependencycheck.analyzer.GolangModAnalyzer.analyzeDependency(GolangModAnalyzer.java:310)
        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)
Caused by: javax.json.JsonException: Cannot auto-detect encoding, not enough chars
        at org.glassfish.json.UnicodeDetectingInputStream.detectEncoding(UnicodeDetectingInputStream.java:130)
        at org.glassfish.json.UnicodeDetectingInputStream.<init>(UnicodeDetectingInputStream.java:75)
        at org.glassfish.json.JsonParserImpl.<init>(JsonParserImpl.java:95)
        at org.glassfish.json.JsonReaderImpl.<init>(JsonReaderImpl.java:73)
        at org.glassfish.json.JsonProviderImpl.createReader(JsonProviderImpl.java:136)
        at javax.json.Json.createReader(Json.java:225)
        at org.owasp.dependencycheck.data.golang.GoModJsonParser.process(GoModJsonParser.java:71)
        ... 8 common frames omitted

To Reproduce
Steps to reproduce the behavior:

  1. Use vendor directory
  2. Execute dependency check's command (fail)
% go list -json -m all
go list -m: can't compute 'all' using the vendor directory
    (Use -mod=mod or -mod=readonly to bypass.)
  1. Execute the proposed new command (ok)
% go list -json -mod=mod -m all > /dev/null; echo $?
0

Expected behavior
Dependency check's Golang Mod Analyzer should be able to list dependencies when vendor directory exists.

bug

All 2 comments

@PurriateCat any thoughts on this? If we run into a vendor directory situation like above should we revert to -mod=mod or -mod=readonly?

Add a fall back to readonly in cases where it fails due to vendor directories.

Was this page helpful?
0 / 5 - 0 ratings