Weird codesign issue with go 1.21.3 build/install on Apple Silicon

daogilvie commented 11 months ago

Description

Mockery binaries don't seem correctly signed on MacOS under go 1.21, even when built from source and ad-hoc signed. I'm on MacOS 13.6 (22G120) on an M1 (so apple silicon).

I have Apple-silicon-using colleagues who do not have this problem — I do not think this is a widespread bug on your code specifically, but it only happens with this repository for me.

I can get the binary to run by re-signing it (codesign -s - mockery). This issue does not occur when installing via brew, because they re-sign everything anyway (see https://github.com/Homebrew/brew/issues/9082). Go wrestled with this first happening in 2020, and this does not happen with other Go code on my machine, whether go installing or go building it.

The tests run fine, so the intermediate test binary being built clearly does not suffer from whatever this problem is.

I'm quite new to Go so might be missing something obvious; if there is something more useful I can do on this issue, then please just let me know.

Thanks for making and improving mockery 👍!

Mockery Version

This seems to be the case with all commits after d5024915e0bbc049b4fb49ce8cb62a68f23fa59e, up to and including 8939c75f51783166286c150e25a50aa8f8b9037c (determined by git bisect).

Golang Version

Error happens with 1.21.0-3

When building with 1.20.6, the binary runs, but there is a build warning printed that seems possibly related:

❯ go build
# github.com/vektra/mockery/v2
ld: warning: '/private/var/folders/w9/5cx7x_sx1d9dmfpz0n_wd6d80000gp/T/go-link-1155392939/go.o' has malformed LC_DYSYMTAB, expected 109 undefined symbols to start at index 14429, found 118 undefined symbols starting at index 73
❯ ./mockery
12 Oct 23 16:21 BST INF Starting mockery dry-run=false version=v0.0.0-dev

Installation Method

[x] Binary Distribution (as downloaded from latest release)
[ ] Docker (pulling from remote archive runs fine, building locally does not and fails with exec /usr/local/bin/mockery: exec format error regardless of requesting amd64 or arm64 builds)
[ ] brew (fine, likely for reasons mentioned in description)
[x] go install (has definitely worked in the past)
[x] Other: built from source

Steps to Reproduce

Clone the repository
go clean -i -r -x
go build; ./mockery
codesign -v mockery will fail, complaining:

mockery: invalid signature (code or signature have been modified)

Expected Behavior

❯ go build; codesign -v mockery;
❯ ./mockery;
12 Oct 23 16:10 BST INF Starting mockery dry-run=false version=v0.0.0-dev

Actual Behavior

❯ go build; codesign -v mockery;
mockery: invalid signature (code or signature have been modified)
In architecture: arm64
❯ ./mockery;
fish: Job 1, './mockery' terminated by signal SIGKILL (Forced quit)

LandonTClipp commented 11 months ago

So along with updating the Go version used in the binary distribution, I also upgraded the action version:

https://github.com/vektra/mockery/commit/8939c75f51783166286c150e25a50aa8f8b9037c#diff-87db21a973eed4fef5f32b267aa60fcee5cbdf03c67fafdc2a9b553bb0b15f34R20

I have a sneaking suspicion this is to blame. Let me check.

LandonTClipp commented 11 months ago

I can't debug this at the moment, I need to get home to my mac laptop and see if I can reproduce this.

I wasn't able to find any smoking gun within the setup-go action, nor with gorereleaser. Although, there are docs in goreleaser for adding os-specific hooks, and funnily enough one of the examples is with using codesign: https://goreleaser.com/customization/builds/?h=codesign#build-hooks

We could probably just do this. Although, I would really like to know what the difference is between your environment and everyone else's.

daogilvie commented 11 months ago

Although, I would really like to know what the difference is between your environment and everyone else's.

You and me both! I'm sure this is some weird thing on my machine, coupled with some corner case in the mockery code, rather than a general problem with mockery.

Thank you for responding so quickly — I am completely unfamiliar with Go internals, and with the details of MacOS code signatures, so I'm really lost on what to check next. Whatever happens I'm sure it'll be a learning experience. To be clear, I'm absolutely fine if the outcome of this issue is a big ole shrug ¯_(ツ)_/¯ and closing it because it just can't be replicated. I hoped if anyone was seeing this too, or knew what I might be able to check next, then this would be the place to find out 😄

daogilvie commented 11 months ago

I think I've identified where the problem might lie, and it's in my specific toolchain of Go for some reason. I will continue to investigate, but I've now managed to replicate on one other non-trivial Go project so I think the ball is back in my court! I'll close the issue here, thank you again for your time, and for maintaining mockery!

daogilvie commented 11 months ago

Just as a note for interest — this was caused for some reason by my Go toolchain using clang from homebrew's latest stable LLVM (17.0.2) instead of cc or regular Xcode tools clang. May learn some more from the wise folks over at brew, but definitely not a mockery problem.

vektra / mockery