search

oven-sh / bun

Incredibly fast JavaScript runtime, bundler, test runner, and package manager – all in one
https://bun.sh
Other
73.54k stars 2.71k forks source link

Cannot code-sign compiled executable on macOS #7208

Open paambaati opened 10 months ago

paambaati commented 10 months ago

What version of Bun is running?

1.0.13+f5bf67bd1

What platform is your computer?

Darwin 23.1.0 arm64 arm

What steps can reproduce the bug?

  1. Build a compiled executable by following https://bun.sh/docs/bundler/executables
  2. Create a self-signed certificate with code-signing capabilities by following https://support.apple.com/en-in/guide/keychain-access/kyca8916/mac

  3. Attempt to code-sign the compiled executable with the command –

    codesign -f -s "Acme Corp" ./mycli --deep

  4. See the error –

    ./mycli: replacing existing signature
./mycli: main executable failed strict validation

What is the expected behavior?

The executable should be code-signed correctly and runnable on the system without Gatekeeper blocks/prompts.

What do you see instead?

./mycli: replacing existing signature
./mycli: main executable failed strict validation

Additional information

FWIW, Deno's compiled binaries face the same issue (although I'm not sure if the root cause is the same) – see https://github.com/denoland/deno/issues/575 and https://github.com/denoland/deno/issues/17753

YoavCodes commented 6 months ago

https://github.com/oven-sh/bun/blob/9e91e137f165a4f5c1be63beaba1a6650852a3b6/src/StandaloneModuleGraph.zig#L1-L3 👀

If it's possible to only incur the 350ms fixed build time increase when I pass in a --makeCodesignable flag or something I think that'd be a good solution (as apposed to finding a more performant solution).

pauldvu commented 3 months ago

https://github.com/oven-sh/bun/blob/9e91e137f165a4f5c1be63beaba1a6650852a3b6/src/StandaloneModuleGraph.zig#L1-L3

👀 If it's possible to only incur the 350ms fixed build time increase when I pass in a --makeCodesignable flag or something I think that'd be a good solution (as apposed to finding a more performant solution).

I agree a flag would be amazing, currently can't ship bun desktop applications without signing

paambaati commented 2 months ago

@Electroid @Jarred-Sumner FWIW, Deno has landed support for codesigning Windows and macOS executables in https://github.com/denoland/deno/pull/24604 and it is expected to land in Deno 1.46.

ctjlewis commented 1 month ago

cc @Jarred-Sumner - we cannot ship binaries to Mac ecosystem yet.

ctjlewis commented 1 month ago

We get:

$ codesign --force --sign ... compiled.bin

main executable failed strict validation

The most we have by way of actual documentation from Apple is from Technical Note TN2206: macOS Code Signing In Depth.

codesign says my main executable failed strict validation.

  • Your Mach-O executable does not conform to modern Mach-O layout rules.
  • You may be using a third party development product that hasn't been brought up to date, or post-processed your file in unsupported ways.
codenoid commented 3 weeks ago

ah, It's not just me, gotta try Deno I guess

edit: Deno single executable was worse

edvald commented 2 weeks ago

This is pretty much a hard requirement for us, and we'd happily take a 350ms hit on build time, especially if it can be toggled only for distribution builds.

edvald commented 2 weeks ago

Btw, Bun team, if you can provide some guidance as to what you tried previously (as per your code comment) we could potentially contribute something along the lines of what @YoavCodes suggested.

YoavCodes commented 2 weeks ago

for what it's worth in the meantime while building https://www.electrobun.dev I implemented code signing on mac. but it essentially builds a mac application bundle (ie: folder) and code signs/notarizes your bundle which includes the bun binary and separate bundled js and other binaries.

so creating an app bundle and code signing/notarizing that is a workaround for distributing a "single" code signed thing.

but it'd be nice to be able to compile and sign/notarize a single binary for cli apps and terminal based utilities.

edvald commented 2 weeks ago

That's interesting, thanks for sharing @YoavCodes! We'll take a closer look.

But still agreed, I think the CLI tool use-case is broadly important for a tool like this. Bun does a lot of stuff super well, not least in the context of CLIs—faster startup times than alternatives and generally very smooth compilation+bundling, among other things—so it'd be a shame to get blocked on a last-mile thing like this.

It'd be a bit difficult to work it out from scratch, but any notes on prior attempts from the Bun team would be great to help others contribute.

Btw I'd also argue that a fixed 350ms cost is not exactly terrible for binary builds, since a lot of rapid iteration happens without those. At any rate an option to make the binary signable at the expense of marginally slower build time would make a lot of sense.

ctjlewis commented 2 weeks ago

Hey guys, just as an update, I’ve talked to Jared about this a few times and everyone is on some page that we gotta be able to sign binaries.

build —binary currently breaks whatever metadata block and that’s why it doesn’t work. I expect within a few versions this will be fixed.

@YoavCodes I was looking into that, do you have any links or notes on distributing the codesigned app folder? The simplest form is actually just App.app/App, no other files.

codenoid commented 2 weeks ago

Here's the way I distribute WebhookPrinter.com Mac package while waiting Bun sign support

image
YoavCodes commented 2 weeks ago

@YoavCodes I was looking into that, do you have any links or notes on distributing the codesigned app folder?

Can take a look at the build command of the Electrobun cli (which is actually an unsigned single-file bun executable itself, distributed via npm that I'd love to sign)

I'm just a guy building an Electron alternative so the code is a bit messy and I probably went further than you'll want to but essentially for distribution it's:

Notes: