invalid package name "" when importing tview

[SamWhited]

Summary

When running gosec against a package on alpine/edge (but not on Feora 34) I get the error:

  > [line 26 : column 2] - could not import github.com/rivo/tview (invalid package name: "")

Steps to reproduce the behavior

go get -u github.com/securego/gosec/cmd/gosec
cd project-that-imports-tview/
gosec ./...

gosec version

Always pulled in CI using go get as above. Last run I see was:

go: downloading github.com/securego/gosec v0.0.0-20200401082031-e946c8c39989

Go version (output of 'go version')

+ go version
go version go1.16.4 linux/amd64

Operating system / Environment

alpine/edge

+ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/build/.cache/go-build"
GOENV="/home/build/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/build/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/build/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.16.4"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build254833280=/tmp/go-build -gno-record-gcc-switches"

Expected behavior

It should run like it used to before this project imported tview.

Actual behavior

  > [line 26 : column 2] - could not import github.com/rivo/tview (invalid package name: "")

This is similar to #580 except not in the standard library so I'm opening this separately.

[mmorel-35]

Have you tried using github.com/securego/gosec/v2 the last release of gosec is v2.7.0

[SamWhited]

I just tried updating to v2 (go get -u github.com/securego/gosec/v2) and now it happens on all platforms, not just in CI.

EDIT: Oops, no, I did not update to v2 because that command is incorrect. However, I just did so and it definitely still happens on all my machines now.

[SamWhited]

Here is an updated CI run that now uses gosec v2 showing the problem, if it helps: https://builds.sr.ht/~samwhited/job/510093#task-lint

Thanks for taking a look!

[mmorel-35]

That's weird because github.com/rivo/tview is not defined in go.mod or go.sum of gosec

[SamWhited]

It's imported by the project being scanned

[mmorel-35]

@ccojocar any idea ?

[mmorel-35]

There is a similar error here

[ccojocar]

@SamWhited I think you are installing the v1 instead of v2 of gosec. Could you try to run this command to install the tool:

go get -u github.com/securego/gosec/v2/cmd/gosec

Also can you make sure that go build runs successfully before running gosec. Thanks!

[ccojocar]

I see that you've tried already v2. What does go build return?

[SamWhited]

Go build and all the other linters I run work just fine

[ccojocar]

@SamWhited Can you provide provide a sample of a project where your issue is reproducible? Thanks!

[SamWhited]

@ccojocar Sure, you can do more or less what the CI run I linked does:

git clone https://git.sr.ht/~samwhited/xmpp
cd xmpp
gosec ./examples/commands/

Wild-ass guess: maybe it's getting confused by the fact that the examples are separate modules from the main library.

[SamWhited]

I noticed today that if I cd into examples/commands first and run gosec everything works. The bug appears to be that it's using the wrong go.mod file so it doesn't know about the dependency on tcell/tview. It should likely ignore examples/commands when you use the ./... selector and then I could manually run it against them separately (which is what most of the builtin go tools do).

[ccojocar]

@SamWhited There is an option available to exclude folders form the scan:

  -exclude-dir value
        Exclude folder from scan (can be specified multiple times)

I would use this option instead of hardcoding the name of these folders into the tool. Is this enough for you? If so, I would close this issue. Thanks!

[SamWhited]

Personally I would expect the behavior to match the rest of the go tooling, there's no need to hardcode directories, just skip nested modules.

[ccojocar]

@SamWhited gosec relies on go build to resolve the go modules, it does not perform any preprocessing related to go modules. I am closing this as out of scope. Thanks

[SamWhited]

The Go build command correctly handles nested modules by skipping the others, so something is still going wrong here. Surely this confusing error should at least be updated though to make it obvious what's going on? I'd still request that something be done about this, even if it's not that the behavior of gosec is updated to match all the other tools. Maybe it's just a documentation or error message issue? /cc @ccojocar