Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
bvwells opened this issue May 25, 2021 · 12 comments
Open

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

bvwells opened this issue May 25, 2021 · 12 comments
Labels
Documentation NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@bvwells
Copy link

bvwells commented May 25, 2021

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 mknyszek changed the title Behaviour of 'go mod graph' with module 'replace' statement cmd/go: 'go mod graph' doesn't show module's replacement May 25, 2021
@mknyszek mknyszek added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label May 25, 2021
@mknyszek mknyszek added this to the Backlog milestone May 25, 2021
@mknyszek
Copy link
Contributor

@bcmills
Copy link
Contributor

bcmills commented May 25, 2021

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
Copy link
Member

dup of #40513 and #32058 ?

@bvwells
Copy link
Author

bvwells commented May 25, 2021

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
Copy link
Author

bvwells commented May 25, 2021

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
Copy link
Contributor

bcmills commented May 25, 2021

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
Copy link
Author

bvwells commented May 27, 2021

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

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
Copy link
Contributor

bcmills commented May 27, 2021

@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
Copy link

sify21 commented Nov 11, 2021

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
Copy link
Contributor

bcmills commented Nov 11, 2021

@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
Copy link

sify21 commented Nov 11, 2021

@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
Copy link
Contributor

bcmills commented Nov 11, 2021

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Documentation NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

5 participants