cmd/go: 'go mod graph' doesn't show module's replacement

[bvwells]

What version of Go are you using (go version)?

$ go version
go version go1.16.4 windows/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=...
set GOENV=...
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=...
set GONOPROXY=...
set GONOSUMDB=...
set GOOS=windows
set GOPATH=...
set GOPRIVATE=...
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=c:\go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=...
set GOVCS=
set GOVERSION=go1.16.4
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=...
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=...

What did you do?

Not completely sure whether this is an issue or what the expected behaviour is here. I've tried to describe the issue here
https://github.com/bvwells/module-graph

This is to clarify the behaviour of 'go mod graph' when the replace is used in a module. The example adds a replace in the module for a dependency. After doing 'go mod tidy' the only version seen in the sum file is the version defined in the replace statement.

Then run 'go mod graph' to output the module graph.

What did you expect to see?

The documentation states:

The go mod graph command prints the module requirement graph (with replacements applied) in text form.

See https://golang.org/ref/mod#go-mod-graph

I was expecting to see the dependency gopkg.in/yaml.v3 replaced with the version gopkg.in/yaml.v3 v3.0.0-20210107192922-496545a6307b.

What did you see instead?

The original dependency versions of gopkg.in/yaml.v3 were seen in the graph.

Apologies if I've misunderstood the documentation.

[mknyszek]

CC @bcmills @jayconrod @matloob via https://dev.golang.org/owners

[bcmills]

go mod graph has a fairly strict output format (constrained by compatibility with digraph), so while it does apply replacements, it does not label them explicitly in the graph.

[seankhliao]

dup of #40513 and #32058 ?

[bvwells]

Apologies if this has been raised before. I did a quick search, but didn't find anything.

If this is the expected behaviour then perhaps it is just a case of documenting the behaviour....

[bvwells]

As a side note, I have a suspecion that some vunerabilty checking tools are using 'go mod graph' to find dependencies and check against known CVEs. Sounds like this is not the way to go...

[bcmills]

Yeah, go mod graph (and the more-or-less-equivalent go list -m all) are not appropriate for checking for vulnerabilities.

The rate of false-positives (for modules that are present in the module graph but not otherwise relevant to the packages or tests in the main module) would be extremely high.

[bvwells]

@bcmills do you think it is worth updating the graph command line documentation here

go/src/cmd/go/internal/modcmd/graph.go

Line 24 in 2ebe77a

Graph prints the module requirement graph (with replacements applied)

to say something like:

Graph prints the module requirement graph (with replacements not applied) 

I'm happy to raise a PR if you think this is the way forward and we can come up with a suitable wording.

[bcmills]

@bvwells, “(with replacements not applied)” is not accurate. The replacements are applied. They replace the source code (and go.mod file contents) of the module with the contents of the indicated path and version, but they do not change the module path or version string for the corresponding node in the module graph.

So if you replace every version of the module gopkg.in/yaml.v3 with gopkg.in/yaml.v3 v3.0.0-20210107192922-496545a6307b, you still have nodes in the module graph for every version that would otherwise be present — they just all effectively have the same source code (and same dependencies) as the replacement version.

(I know that this behavior is not particularly intuitive, but it's also difficult to fix to match folks' intuition without breaking other things. I'm planning to revamp replace in general for Go 1.18. See also #26344 and #26904.)

[sify21]

Yeah, go mod graph (and the more-or-less-equivalent go list -m all) are not appropriate for checking for vulnerabilities.

The rate of false-positives (for modules that are present in the module graph but not otherwise relevant to the packages or tests in the main module) would be extremely high.

@bcmills Do you mean that go list -m all would also print modules that are not relevant to the packages or tests in the main module? But the ref says it prints the build list:

MVS produces the build list as output, the list of module versions used for a build.

The build list may be inspected with the command go list -m all.

[bcmills]

@sify21 Yes, go list -m all prints the version of any module whose selected version is above none (i.e. any module that appears in the module graph at all), even if that module is not otherwise relevant.

The term “build list” is a bit of a misnomer, but it has a consistent meaning in the documentation. Per https://golang.org/ref/mod#glos-build-list:

… The build list contains versions for all modules in the module graph, not just those relevant to a specific command.

[sify21]

@bcmills Oh I see, do you know any other method to get those relevant modules? Or is it that different commands have different relevent modules?

[bcmills]

That's getting a bit off-topic for this issue. (See #42504 instead.)