-
Notifications
You must be signed in to change notification settings - Fork 17.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd/go: install produces executable with invalid signature (macOS) #63997
Comments
I was able to work around this issue by resigning the binary: codesign -f -s - /Users/nils/Work/go/bin/gopls And now it works: gopls -v version
Build info
----------
golang.org/x/tools/gopls v0.14.1
golang.org/x/tools/gopls@v0.14.1 h1:XaTETpi7Q67XO8nftquJitcx+9c2bPclO8Kz2sBVvec=
github.com/BurntSushi/toml@v1.2.1 h1:9F2/+DoOYIOksmaJFPw1tGFy1eDnIJXg+UHjuD8lTak=
github.com/google/go-cmp@v0.5.9 h1:O2Tfq5qg4qc4AmwVlvv0oLiVAGB7enBSJ2x2DqQFi38=
github.com/sergi/go-diff@v1.1.0 h1:we8PVUC3FE2uYfodKH/nBHMSetSfHDR6scGdBi+erh0=
golang.org/x/exp/typeparams@v0.0.0-20221212164502-fae10dda9338 h1:2O2DON6y3XMJiQRAS1UWU+54aec2uopH3x7MAiqGW6Y=
golang.org/x/mod@v0.13.0 h1:I/DsJXRlw/8l/0c24sM9yb0T4z9liZTduXvdAWYiysY=
golang.org/x/sync@v0.4.0 h1:zxkM55ReGkDlKSM+Fu41A+zmbZuaPVbGMzvvdUPznYQ=
golang.org/x/sys@v0.13.0 h1:Af8nKPmuFypiUBjVoU9V20FiaFXOcuZI21p0ycVYYGE=
golang.org/x/telemetry@v0.0.0-20231011160506-788d5629a052 h1:1baVNneD/IRxmu8JQdBuki78zUqBtZxq8smZXQj0X2Y=
golang.org/x/text@v0.13.0 h1:ablQoSUd0tRdKxZewP80B+BaqeKJuVhuRxj/dkrun3k=
golang.org/x/tools@v0.14.1-0.20231026192422-8b5abd452b28 h1:5YgdZAe2w0x3Xrjv0+GXrI0jvm7qCQK/ySGFfiEHMfU=
golang.org/x/vuln@v1.0.1 h1:KUas02EjQK5LTuIx1OylBQdKKZ9jeugs+HiqO5HormU=
honnef.co/go/tools@v0.4.5 h1:YGD4H+SuIOOqsyoLOpZDWcieM28W47/zRO7f+9V3nvo=
mvdan.cc/gofumpt@v0.4.0 h1:JVf4NN1mIpHogBj7ABpgOyZc65/UUOkKQFkoURsz4MM=
mvdan.cc/xurls/v2@v2.4.0 h1:tzxjVAj+wSBmDcF6zBB7/myTy3gX9xvi8Tyr28AuQgc=
go: go1.21.3 |
I'm unfamiliar with code signing, but found #42684, which also relates to arm64. I don't see how this problem could be specific to gopls: are you able to install and run other go programs using (asking to confirm before I CC compiler folks) |
I have not had any problems with Not sure why I see this problem, I have another dev machine where I have not seen the same issue. Also, not sure I can reproduce the original problem now that I fixed it using |
Actually, I can reproduce it! If I delete
|
Thanks for following up. Can you please try installing gopls@v0.13.2 (an older version) to see if the outcome is different?
Then can you try installing another arbitrary binary from x/tools, to see if it works? Say:
Can you do |
gopls@v0.13.2 gonew@latest
|
Thanks @koliyo for confirming. CC @golang/compiler -- does anyone have an idea why the gopls binary would require signing? It seems like this just started happening in the past couple weeks, and may be limited to arm64 based on the reports I've seen. |
macOS on ARM64 requires all binaries to be signed, How is the binary installed? Do you by any chance overwrite an existing binary (like using the Do you just run the |
This is a "fresh" binary, installed with I do not do any other operation than the install command. Normally I install gotools using VSCode. It is possible that I have used |
Hmm. I'm a bit out of my depth here, but here are a couple ideas to try based on @cherrymui's comment:
TEMP_GOBIN=$(mktemp -d)
GOBIN=$TEMP_GOBIN go install golang.org/x/tools/gopls@latest
$TEMP_GOBIN/gopls version |
Interesting. If a fresh |
I was getting the same issue, after cleaning the cache and doing a fresh install, it worked right. (Sorry, forgot to get PD: A complete computer restart did not fix the issue neither, and it happened with previous gopls versions too (I tested down to 0.13.0) |
CC @bcmills, in case this is related to the build cache. It sounds like gopls is not directly involved here: its contribution is being a common binary that gets (re)installed frequently. |
My understanding is that code-signing happens either at link time or afterward. So I'm not sure why clearing the build cache would do anything, beyond perhaps causing the program to be rebuilt again. Although, if you run |
Tmp bin directory, same error: TEMP_GOBIN=$(mktemp -d)
GOBIN=$TEMP_GOBIN go install golang.org/x/tools/gopls@latest
$TEMP_GOBIN/gopls version
[1] 34632 killed $TEMP_GOBIN/gopls version Clean cache does not seem to work for me: go clean -cache
rm ~/Work/go/bin/gopls
go install golang.org/x/tools/gopls@latest
~/Work/go/bin/gopls
[1] 34445 killed ~/Work/go/bin/gopls Here is my env: go env
GO111MODULE='on'
GOARCH='arm64'
GOBIN=''
GOCACHE='/Users/nils/Library/Caches/go-build'
GOENV='/Users/nils/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/nils/Work/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/nils/Work/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/opt/homebrew/Cellar/go/1.21.4/libexec'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/opt/homebrew/Cellar/go/1.21.4/libexec/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.21.4'
GCCGO='gccgo'
AR='ar'
CC='clang'
CXX='clang++'
CGO_ENABLED='1'
GOMOD='/dev/null'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/7w/r3zd6mzj6jngg60zxf7q383h0000gn/T/go-build3163292121=/tmp/go-build -gno-record-gcc-switches -fno-common' |
I don't think this is directly related to gopls, but we have seen an increase in these reports via the VS Code Go issue tracker. I do wonder what changed. @cherrymui @bcmills any idea how to proceed? |
I don't know much about how macOS code-signing works, unfortunately. It would really help if we had some way to reproduce it. For similar issues in the past I have requested that users tar up the contents of Unfortunately, in this case I suspect that |
I tried to What version of macOS do you use? And C toolchain (Xcode) version? |
This does work!
So it seems like there is some kind of system level caching of signatures that is messed up? Specifically on my machine. XCode 15.0.1 |
Ok, I have found some additional hints! I have been using zsh for a long time, and also when this bug was reported. But since then I have changed to fish. The fix with But, what I discovered is that I can't even compile go code (with c includes) on my relatively unmodified fish environment:
I have looked at my environment variables, but was unable to deduce the issue. I asked ChatGPT and was suggested the following:
And after this updated env I can compile gopls in fish shell. And what is even more interesting, it does produce a working executable, even without I do not have Anyway there seem to be something going on with include/library paths at some level. Ok update. I have ccache installed and have added to the front of PATH to activate ccache:
True for both zsh and fish But ccache is only an indirection to the actual clang, via symlink, and I discovered that fish was using xcode clang while zsh was using homebrew clang fish:
zsh:
Then I added
And as before, SDKROOT was never defined in zsh. And to reiterate, if I in fish define SDKROOT, I can now compile gopls which does verify and run properly, without the cgo definition. Hope this give you guys some clues. |
Discovered another difference between fish and zsh on my machine. Zsh had In fish:
in zsh:
if I export |
Thanks for the investigation. I could imagine ccache causes problems. I think generally Apple's C toolchain works better than a custom installed one. Could you try setting
This looks like the environment being mis-configured. Could you build any C program that |
Yeah, this is interesting, simple hello world c program, fails with xcode clang, but not with
|
They are the same version, but yet different:
|
What is the version of |
It is not a symlink either
Also, I have now removed ccache from path, with same result, so does not seem to be ccache dependent:
|
NOTE: |
I think /usr/bin/clang is usually not a symlink but a compiled wrapper program that invokes clang using xcrun. I'd suggest you try to install an unbroken Xcode, and set CC to its clang and see if you can still reproduce the Go issue. Thanks. |
The problem seems to be the order of my shell paths (which are propagated into VSCode). As long as i keep I will try and keep |
Thanks. Sounds like we can close this issue. Feel free to reopen if there is anything that still needs to be addressed from the Go side. Thanks. |
Thanks so much @koliyo for following up on this issue. We've seen similar reports from several users, and without your diligence it may have taken us a very long time to figure this out on our own. Thank you @cherrymui for the sage advice and help investigating! |
In my case singing failed for gopls because of including custom llvm toolchain into PATH's:
I have remove those and problem was gone. Kudos to @koliyo ! |
My reason was this one. Be careful about what compiler toolchain you are using. |
I can not launch gopls at all. It is immediately killed
I have looked in system console and it seems this is related to code signing:
Not sure what to do about this
Here is an example of such ips file:
gopls version
Not possible to check, using
gopls -v version
:But I installed latest gopls version, using VSCode update functionality
go env
What did you do?
What did you expect to see?
What did you see instead?
Editor and settings
Logs
The text was updated successfully, but these errors were encountered: