Description
What version of Go are you using (go version
)?
$ go version go version go1.19.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=C:\Users\James\AppData\Local\go-build set GOENV=C:\Users\James\AppData\Roaming\go\env set GOEXE=.exe set GOEXPERIMENT= set GOFLAGS= set GOHOSTARCH=amd64 set GOHOSTOS=windows set GOINSECURE= set GOMODCACHE=C:\Users\James\go\pkg\mod set GONOPROXY= set GONOSUMDB= set GOOS=windows set GOPATH=C:\Users\James\go set GOPRIVATE= set GOPROXY=https://proxy.golang.org,direct set GOROOT=C:\Program Files\Go set GOSUMDB=sum.golang.org set GOTMPDIR= set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64 set GOVCS= set GOVERSION=go1.19.4 set GCCGO=gccgo set GOAMD64=v1 set AR=ar set CC=gcc set CXX=g++ set CGO_ENABLED=1 set GOMOD=C:\workspace\golang.org\x\sys\go.mod set GOWORK= 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 -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=C:\Users\James\AppData\Local\Temp\go-build2317869406=/tmp/go-build -gno-record-gcc-switches
What did you do?
I'm trying to run gqlgen (https://github.com/99designs/gqlgen) as part of a Bazel build.
What did you expect to see?
There should be some way to make gqlgen run correctly in Bazel
What did you see instead?
gqlgen fails with the error: go resolves to executable in current directory (.\external\go_sdk\bin\go.exe)
I originally commented on the execabs proposal here: #43724 (comment)
Bazel makes it intentionally difficult to ever get an absolute path in order to make builds more hermetic. To that end, Bazel runs executable files in this arrangement:
- CWD is a specially-built "execroot" directory which contains all the executable step's dependencies
- PATH is empty unless rule authors explicitly add elements to it
- rule authors are only able to add relative paths to PATH
This creates a somewhat-unusual situation where the paths to be found by exec.LookPath
/execabs.LookPath
aren't absolute, but they also aren't files directly in CWD. Since the paths aren't absolute, the current behavior of exec.LookPath
/execabs.LookPath
is to return an error. However, my understanding is that the LookPath security vulnerability is only relevant if the relative directory is conventionally listed on PATH variables in interactive sessions, but the only such conventionally-used relative path that I'm aware of is .
. If it's true that .
is the only relative path that regularly appears on users' PATH variables, I think it should be safe to update the enforcement check to allow relative paths outside of .
:
if !filepath.IsAbs(path) && filepath.Dir(path) == '.' && godebug.Get("execerrdot") != "0" {
return path, &Error{file, ErrDot}
}