go-fuzz-build doesn't work with go modules (go 1.11.2)

[sashka]

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'

[dvyukov]

Please try inside GOPATH. Building outside of GOPATH was never tested nor intended to work.

[sashka]

OK, I'll dig into the first case.

[dvyukov]

Another reason to remember golang/go#19109

[Crypt-iQ]

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 path error. I found that running go-fuzz in /Users/{user}/go worked for me. Not ideal because then the binary is not created in the project directory... but at least it works!

[dvyukov]

I do not have any updates on this.

[odeke-em]

Hello there, I've also just encountered this with

$ go-fuzz-build github.com/census-instrumentation/opencensus-service/fuzz/receivers/zipkin
package dir '/Users/emmanuelodeke/go/pkg/mod/github.com/dvyukov/go-fuzz@v0.0.0-20190215131527-76990782bc83/go-fuzz-dep' does not end with import path 'github.com/dvyukov/go-fuzz/go-fuzz-dep'

@dvyukov perhaps it might be useful to create releases for this repository or even initialize it with go-modules?

[odeke-em]

Kindly paging @bcmills :) #sorryForTheRandomPing

[thepudds]

See also #219

[thepudds]

Inlining Josh's comment from #219 (comment) now that #219 is closed as a dup:

I suspect (but have not tried) that all that is required to add module support is to (a) copy go.mod if present while copying packages and (b) synthesize a go.mod alongside our synthesized package main.

I intend to work on module support at some point, but it isn't high on my list at the moment. I suppose it should be higher. I'd be happy to review a PR.

In addition to that outline from Josh, I suspect:

• the go.mod for the synthesized package main might need a replace directive back to the on-disk location of the module being fuzzed, such as replace github.com/some/fuzztarget => /tmp/blah/blah/fuzztarget or similar.
• there also might be a need to set env variable GO111MODULE=on explicitly, or alternatively perhaps not set any GOPATH env variable for the temp directory?

However, I could also imagine being wrong about those things. ;-)

Some additional background on replace is in this FAQ from the modules wiki page. Some additional background on enabling module mode for the go command via GO111MODULE or similar is in this other FAQ.

For reference, I think this is where the package main is created and written in go-fuzz-build:

go-fuzz/go-fuzz-build/main.go

Lines 556 to 562 in 9cfa592

	func (c *Context) createFuzzMain() string {
	mainPkg := filepath.Join(c.fuzzpkg.PkgPath, "go.fuzz.main")
	path := filepath.Join(c.workdir, "gopath", "src", mainPkg)
	c.mkdirAll(path)
	c.writeFile(filepath.Join(path, "main.go"), c.funcMain())
	return mainPkg
	}

[pzl]

for what it's worth, this worked fine with a mod-vendored project with minimal changes.

index 324fc7c..fa57092 100644
--- a/go-fuzz-build/main.go
+++ b/go-fuzz-build/main.go
@@ -58,7 +58,6 @@ func makeTags() string {
 // that clients can then modify and use for calls to go/packages.
 func basePackagesConfig() *packages.Config {
    cfg := new(packages.Config)
-   cfg.Env = append(os.Environ(), "GO111MODULE=off")
    return cfg
 }
 
@@ -234,7 +233,7 @@ func (c *Context) loadPkg(pkg string) {
    // See https://golang.org/issue/30826 and https://golang.org/issue/30828.
    rescfg := basePackagesConfig()
    rescfg.Mode = packages.NeedName
-   rescfg.BuildFlags = []string{"-tags", makeTags()}
+ rescfg.BuildFlags = []string{"-mod=vendor", "-tags", makeTags()}
    respkgs, err := packages.Load(rescfg, pkg)
    if err != nil {
        c.failf("could not resolve package %q: %v", pkg, err)
@@ -254,7 +253,7 @@ func (c *Context) loadPkg(pkg string) {
    // of invalid code than trying to compile instrumented code.
    cfg := basePackagesConfig()
    cfg.Mode = packages.LoadAllSyntax
-   cfg.BuildFlags = []string{"-tags", makeTags()}
+ cfg.BuildFlags = []string{"-mod=vendor", "-tags", makeTags()}
    // use custom ParseFile in order to get comments
    cfg.ParseFile = func(fset *token.FileSet, filename string, src []byte) (*ast.File, error) {
        return parser.ParseFile(fset, filename, src, parser.ParseComments)

obviously this is just force-setting things to use go -mod=vendor all the time, but as a POC, it works.

It might help to see how the golangci-lint project loads things? https://github.com/golangci/golangci-lint/blob/master/pkg/lint/load.go#L226

There is a config (file or CLI param) to set your preferred -mod= mode, if you're using modules, otherwise ignores and doesn't put -mod in the BuildFlags

[pzl]

Hmm, it seems it actually may have pulled from $GOPATH/pkg/mod/<import> when performing the build.

It didn't use vendor/ entirely. Missed a few BuildFlag changes.

That being said, vendor or not, module support might be not painful to implement here.

reference:

$ go version
go version go1.12.4 linux/amd64

[sashka]

Looks like it works these days.
Closing the issue.

[ririsoft]

go-fuzz-build still does not work with go modules.
Can you consider reopening the issue please ?

[sashka]

OK. Reopened.

[yevgenypats]

@dvyukov @josharian I would like to work (me or some one from my team) on this issue. But before jumping and implementing I wanted to understand how complicated this is and how it should be implemented in terms of the design? we can come up with a proposal as well but wanted to see if there is already an idea in mind?

[dvyukov]

I can't help much. I don't know what modules are. On user interface level we try to mimic go tool as much as possible. On implementation level I don't have any concrete thoughts.
@josharian?

[yevgenypats]

ccing also @mvdan as I know you did some hacky work arounds. maybe you have a suggestion in mind?

[mvdan]

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:

• create a nested module that depends on the main module via a replace (see go.mod), and that contains fuzz.go
• use a script to create a GOPATH with all necessary packages; see fuzz-gopath, this is possible with a few lines thanks to go mod vendor
• run go-fuzz-build with the GOPATH set up above (and modules turned off); see fuzz-ci

As a bonus point, you can also track/pin the version of go-fuzz-build via go.mod; see tools.go. This system takes a bit of setup, but it works well for me.

[josharian]

I would like to work (me or some one from my team) on this issue.

Great!

But before jumping and implementing I wanted to understand how complicated this is and how it should be implemented in terms of the design? we can come up with a proposal as well but wanted to see if there is already an idea in mind?

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. :)

On user interface level we try to mimic go tool as much as possible. On implementation level I don't have any concrete thoughts.

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 pretty sure @josharian has a master plan here, I just don't know if he's made it public :)

I'm afraid that my master plan was: "get in there and figure it out".

[bookmoons]

@mvdan Your pattern is working well for me. Thanks for posting it.

Do you know if it's possible to fuzz a private function in the target package? I'm trying to adapt some fuzz targets that hit private functions. Not sure if there's a way to get at them from the fuzz module.

[thepudds]

We'll see how things end up, but most likely google/oss-fuzz#2878 needs to land first before landing modules support in go-fuzz. (google/oss-fuzz#2878 is a hopefully a small change).

[yevgenypats]

@thepudds any news with google/oss-fuzz#2878?

[yevgenypats]

@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?

[thepudds]

@thepudds any news with google/oss-fuzz#2878?

Hello @yevgenypats, there seems to be some loose consensus there, but it is still open. I just pinged one of the oss-fuzz owners. If you don't see progress there soon, you could add a friendly ping there if you want.

[yevgenypats]

Hey @thepudds, sure, I can add a friendly ping. In the meantime I suggest #271 to remove pressure and give the users that are blocked by this feature to opt-in.

[thepudds]

For anyone who is particularly eager to see modules support land, one good and hopefully quick way to help would be sending a PR for issue #252.

(That is not a gate on initial modules support, but it would help).