macos executable can't be code-signed

[maxpavlov]

I think all bundlers have gone through this.

An executable packaged with caxa on maOS with the following command:
caxa -i bundle -o myclitool -- "{{caxa}}/node_modules/.bin/node" "{{caxa}}/main.js"
while works as expected, can't be signed like so:
codesign --deep --force --options=runtime --entitlements ./entitlements.plist --sign [MASKED] --timestamp myclitool

An attempt to sign produces an error: myclitool: main executable failed strict validation

Similar error has haunted vercel/pkg but was fixed there with this PR, which might provide a hint on why this is happening.

Thanks in advance for any suggestions on how to work around this.

[leafac]

Hi @maxpavlov, Thanks for reaching out and for doing this preliminary investigation. I haven’t dug into signing yet, so I don’t have good answers so far. I’ll get to it at some point.

[bowbahdoe]

Any updates?

[leafac]

Hi @bowbahdoe,

Thanks for reaching out!

I’m afraid I don’t have updates. I haven’t looked into the issue myself yet, and I don’t know of anyone working on it right now.

Do you think you can tackle it? Perhaps you already did a little investigation and can add some information?

Best.

[mountaindude]

@maxpavlov Were you able to solve this?

I'm struggling with this too, with recent (v19) Node versions. Including Puppeteer >20.0 causes all kinds of problems with pkg (but code signing works there), whereas Puppeteer with caxa works great, but code signing doesn't work. Sigh.

No Go or native macOS experience unfortunately.

[jowparks]

So I ran into this issue as well when trying to sign for OSX. It seems like the issue is that the binary is being modified after it is compiled. The artictecture of caxa would need to change such that the the binary is created by the go build rather than adding the javascript to the end of the stub binary.

When I generate just the stub binary with cross-env CGO_ENABLED=0 GOOS=darwin GOARCH=amd64 go build -o stubs/stub--darwin--x64 stubs/stub.go, the code signing works just fine.

I did a little reading on go and it seems like you can embed files in go binaries
https://stackoverflow.com/questions/17796043/how-to-embed-files-into-go-binaries

This seems like a pretty major architectural change to caxa and I am wondering if @leafac has any opinion on it.

[leafac]

Hi y’all,

Thanks for using caxa and for the conversation here.

I’ve been thinking about the broad strategy employed by caxa and concluded that there is a better way to solve the problem. It no longer uses a stub, and I wonder how it’ll interact with code signing (perhaps it won’t be necessary at all 🤔). Can you please give it a try and report back?

It’s a different enough approach that I think it deserves a new name, and it’s part of a bigger toolset that I’m building, which I call Radically Straightforward · Package.

I’m deprecating caxa and archiving this repository. I invite you to continue the conversation in Radically Straightforward’s issues.

Best.