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}
}
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env)?go envOutputWhat 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:
This creates a somewhat-unusual situation where the paths to be found by
exec.LookPath/execabs.LookPatharen't absolute, but they also aren't files directly in CWD. Since the paths aren't absolute, the current behavior ofexec.LookPath/execabs.LookPathis 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.: