go-fuzz: go-fuzz-build doesn't work with go modules (go 1.11.2)
FTR: I’m going to investigate this issue a bit. If the problem is on my side, I will close the issue.
Environment:
> go version
go version go1.11.2 darwin/amd64
> go env GOROOT GOPATH
/usr/local/Cellar/go/1.11.2/libexec
/Users/asd/go
Steps to reproduce inside GOPATH:
> pwd
/Users/asd/go/src/github.com/sashka/signedvalue
> go-fuzz-build github.com/sashka/signedvalue
failed to execute go build: exit status 1
go: finding github.com/dvyukov/go-fuzz v0.0.0-20181106053552-383a81f6d048
go: finding github.com/stephens2424/writerset v0.0.0-20150719204953-fe01f9c9e73f
go: finding github.com/elazarl/go-bindata-assetfs v1.0.0
go: finding github.com/sashka/signedvalue/go.fuzz.main latest
can't load package: package github.com/sashka/signedvalue/go.fuzz.main: unknown import path "github.com/sashka/signedvalue/go.fuzz.main": cannot find module providing package github.com/sashka/signedvalue/go.fuzz.main
Steps to reproduce outside GOPATH:
> cd /tmp
> git clone git@github.com:sashka/signedvalue
Cloning into 'signedvalue'...
...
> cd signedvalue/
> go-fuzz-build github.com/sashka/signedvalue
package dir 'go: finding github.com/dvyukov/go-fuzz/go-fuzz-dep latest
go: finding github.com/dvyukov/go-fuzz latest
/Users/asd/go/pkg/mod/github.com/dvyukov/go-fuzz@v0.0.0-20181106053552-383a81f6d048/go-fuzz-dep' does not end with import path 'github.com/dvyukov/go-fuzz/go-fuzz-dep'
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 3
- Comments: 26 (10 by maintainers)
Commits related to this issue
- Disable go modules for fuzzing Issue: https://github.com/dvyukov/go-fuzz/issues/195 — committed to trustelem/zxcvbn by vanackere 5 years ago
- go-fuzz-build: set GO111MODULE=off while building Updates #195 Updates google/oss-fuzz/pull#2188 — committed to josharian/go-fuzz by josharian 5 years ago
- go-fuzz-build: set GO111MODULE=off while building Updates #195 Updates google/oss-fuzz/pull#2188 — committed to dvyukov/go-fuzz by josharian 5 years ago
- go-fuzz-build: set GO111MODULE=off for all go/packages calls This is a follow-up to #237. Updates #195 Updates google/oss-fuzz/pull#2188 — committed to josharian/go-fuzz by josharian 5 years ago
- go-fuzz-build: set GO111MODULE=off for all go/packages calls This is a follow-up to #237. Updates #195 Updates google/oss-fuzz/pull#2188 — committed to dvyukov/go-fuzz by josharian 5 years ago
- Add support for Go modules based on https://github.com/dvyukov/go-fuzz/issues/195#issuecomment-493487388 — committed to disconnect3d/go-fuzz by disconnect3d 5 years ago
- go-fuzz-build: respect GO111MODULE if set This is an alternative to #271. Updates #195 — committed to josharian/go-fuzz by josharian 5 years ago
- go-fuzz: set explictly GO111MODULES=off This will prevent breaking go-fuzz when it will support go modules https://github.com/dvyukov/go-fuzz/issues/195 and addressing this issue: https://github.com... — committed to fuzzitdev/oss-fuzz by deleted user 5 years ago
- [golang] set explictly GO111MODULES=off (#2914) This will prevent breaking go-fuzz when it will support go modules https://github.com/dvyukov/go-fuzz/issues/195 and addressing this issue: https:... — committed to google/oss-fuzz by yevgenypats 5 years ago
- go-fuzz-build: set GO111MODULE=off while building Updates #195 Updates google/oss-fuzz/pull#2188 — committed to bradleyjkemp/simple-fuzz by josharian 5 years ago
- go-fuzz-build: set GO111MODULE=off for all go/packages calls This is a follow-up to #237. Updates #195 Updates google/oss-fuzz/pull#2188 — committed to bradleyjkemp/simple-fuzz by josharian 5 years ago
- Port the clang-fuzzer code to the Makefile. Still doesn't work because Prometheus client_golang broke everything for non-modules in github.com/prometheus/client_golang/commit/ee1078a03c073762e2660d30... — committed to google/mtail by jaqx0r 5 years ago
- COmment out the fuzzer steps as they're broken until dvyukov/go-fuzz/issues/195 is resolved. — committed to google/mtail by jaqx0r 5 years ago
- Vendor module deps in circleci fuzz build so that go-fuzz-build can find them. Until https://github.com/dvyukov/go-fuzz/issues/195 is fixed, we need to vendor as some dependencies are only modules an... — committed to google/mtail by jaqx0r 5 years ago
I’m pretty sure @josharian has a master plan here, I just don’t know if he’s made it public 😃
Anyone is free to copy what I did here: https://github.com/mvdan/sh/tree/master/_fuzz/it
The steps are:
go.mod), and that containsfuzz.goGOPATHwith all necessary packages; seefuzz-gopath, this is possible with a few lines thanks togo mod vendorgo-fuzz-buildwith theGOPATHset up above (and modules turned off); seefuzz-ciAs a bonus point, you can also track/pin the version of
go-fuzz-buildviago.mod; seetools.go. This system takes a bit of setup, but it works well for me.OK. Reopened.
go-fuzz-build still does not work with go modules. Can you consider reopening the issue please ?
Another reason to remember https://github.com/golang/go/issues/19109
Hey @thepudds, sure, I can add a friendly ping. In the meantime I suggest https://github.com/dvyukov/go-fuzz/pull/271 to remove pressure and give the users that are blocked by this feature to opt-in.
@thepudds maybe we can do some incremental addition of this feature. i.e by adding some flag that enable this support until google/oss-fuzz#2878 is solved?
We’ll see how things end up, but most likely https://github.com/google/oss-fuzz/issues/2878 needs to land first before landing modules support in go-fuzz. (https://github.com/google/oss-fuzz/issues/2878 is a hopefully a small change).
Great!
A short proposal is a fine way to proceed. It is possible that to understand enough to write a proposal you will find you need to actually implement most/all of it. If that happens, it is also ok to put the proposal in the commit message and send a PR. 😃
I would hope that there would be no interface-level impact at all. go-fuzz-build should “just work” on both module-using and non-module-using packages.
I’m afraid that my master plan was: “get in there and figure it out”.
Any updates on this? I experienced similar problems while trying to fuzz another project. I tried running go-fuzz in the project directory itself and received the
unknown import patherror. I found that running go-fuzz in/Users/{user}/goworked for me. Not ideal because then the binary is not created in the project directory… but at least it works!