tfausak / cabal-gild

:crown: Format Haskell package descriptions.
https://hackage.haskell.org/package/cabal-gild
MIT License
48 stars 5 forks source link

`gild` gets terminated by `SIGKILL` on M1 macOS #24

Closed sondr3 closed 8 months ago

sondr3 commented 8 months ago

I downloaded the arm64 variant of the binary and made it executable, but it just errors out immediately:

❯ file cabal-gild-1.0.2.0-darwin-arm64
cabal-gild-1.0.2.0-darwin-arm64: Mach-O 64-bit executable arm64

❯ ./cabal-gild-1.0.2.0-darwin-arm64
fish: Job 1, './cabal-gild-1.0.2.0-darwin-arm…' terminated by signal SIGKILL (Forced quit)

I'm guessing this is some form of GHC miscompilation that strikes again. The x64 binary works fine.

tfausak commented 8 months ago

Huh, that's weird.

I haven't used GitHub's new M1 macOS runners before. I'm not sure if the problem is with GHC, macOS, GitHub, or something else.

I thought maybe Gatekeeper was the problem, but I couldn't get it working even with some various xattr and codesign commands.

I don't really know how to proceed here. I may need to sign/notarize the binary.

sondr3 commented 8 months ago

I'm not sure it's codesigning, I've signed the binary manually locally using both codesign and rcodesign and it still exits with SIGKILL. Compiling and running it locally works fine and the codesign tool says no issues with it, and comparing the output doesn't tell me anything is wrong with it.

``` ❯ codesign -dvv ./cabal-gild-1.0.2.0-darwin-arm64 Executable=/Users/sondre/code/haskell/cabal-gild/cabal-gild-1.0.2.0-darwin-arm64 Identifier=cabal-gild-1.0.2.0-darwin-arm64 Format=Mach-O thin (arm64) CodeDirectory v=20400 size=34008 flags=0x2(adhoc) hashes=1057+2 location=embedded Signature=adhoc Info.plist=not bound TeamIdentifier=not set Sealed Resources=none Internal requirements count=0 size=12 ❯ codesign -dvv dist-newstyle/build/aarch64-osx/ghc-9.8.1/cabal-gild-1.0.2.0/x/cabal-gild/build/cabal-gild/cabal-gild Executable=/Users/sondre/code/haskell/cabal-gild/dist-newstyle/build/aarch64-osx/ghc-9.8.1/cabal-gild-1.0.2.0/x/cabal-gild/build/cabal-gild/cabal-gild Identifier=cabal-gild Format=Mach-O thin (arm64) CodeDirectory v=20400 size=314339 flags=0x20002(adhoc,linker-signed) hashes=9820+0 location=embedded Signature=adhoc Info.plist=not bound TeamIdentifier=not set Sealed Resources=none Internal requirements=none ```
sondr3 commented 8 months ago

I tried running the binary in lldb to see what it says, it errors with error: Bad executable.

``` ❯ lldb -o run -- ./dist-newstyle/build/aarch64-osx/ghc-9.8.1/cabal-gild-1.0.2.0/x/cabal-gild/build/cabal-gild/cabal-gild --help (lldb) target create "./dist-newstyle/build/aarch64-osx/ghc-9.8.1/cabal-gild-1.0.2.0/x/cabal-gild/build/cabal-gild/cabal-gild" Current executable set to '/Users/sondre/code/haskell/cabal-gild/dist-newstyle/build/aarch64-osx/ghc-9.8.1/cabal-gild-1.0.2.0/x/cabal-gild/build/cabal-gild/cabal-gild' (arm64). (lldb) settings set -- target.run-args "--help" (lldb) run cabal-gild version 1.0.2.0 -h, -? --help Shows this help message. --no-help -v --version Shows the version number. --no-version -i FILE --input=FILE Sets the input file. Use '-' for standard input (STDIN). Default: '-' -m MODE --mode=MODE Sets the mode. Must be either 'check' or 'format'. Default: 'format' -o FILE --output=FILE Sets the output file. Use '-' for standard output (STDOUT). Default: '-' -s FILE --stdin=FILE Sets the path to the input file when using STDIN. Default: '.' Process 67902 exited with status = 0 (0x00000000) Process 67902 launched: '/Users/sondre/code/haskell/cabal-gild/dist-newstyle/build/aarch64-osx/ghc-9.8.1/cabal-gild-1.0.2.0/x/cabal-gild/build/cabal-gild/cabal-gild' (arm64) (lldb) ^D ❯ lldb -o run -- ./cabal-gild-1.0.2.0-darwin-arm64 --help (lldb) target create "./cabal-gild-1.0.2.0-darwin-arm64" Current executable set to '/Users/sondre/code/haskell/cabal-gild/cabal-gild-1.0.2.0-darwin-arm64' (arm64). (lldb) settings set -- target.run-args "--help" (lldb) run error: Bad executable (or shared library) (lldb) ^D ```
gitperr commented 8 months ago

If you compile locally, it gets linker signed, so it will run on that mac without issues.

If you want to run that same build you compiled locally, on another mac, you'll need to code sign (with at least adhoc method). But that sometimes does not work well either. I'd recommend paying Apple 99$ yearly and getting into the developer program. Then, you can get the actual certificates and sign with them. It will run on any mac with no problem afterwards.

rcodesign is a workaround, but afaik you should be able to feed the apple certificates to it... (I haven't tested this)

sondr3 commented 8 months ago

That does not sound correct, all the binaries I've installed via Homebrew work and they only sign using the ad-hoc method: https://github.com/Homebrew/brew/blob/6a9c9c00a028cf0bcf7da5a9e5b28c861a981ebd/Library/Homebrew/extend/os/mac/keg.rb#L33.

edit: you may be right about the linker-signed thing though, not sure how that works on CI/similar, but the codesigning with a certificate seems to be a different thing.

edit2: I just added macos-14 to one of my own projects and published it (using Rust/cargo, but still similar) and I can download the git-ignore-aarch64-apple-darwin.tar.gz package and run the binary no issues.

gitperr commented 8 months ago

Ad-hoc one works when you install with curl, wget and tools alike (I think Homebrew also under the hood used one of those...). If you try to download it via Safari for example, then you will likely run into problems.

sondr3 commented 8 months ago

Doesn't work with either curl or wget for me sadly, it still gets SIGKILLed.

gitperr commented 8 months ago

Could you check what the output of this is?

codesign -vvvv <path_to_your_binary>

That might give some useful info about code signature.

And then there is the option to make this a system service and run like that. If I recall, that gives some more info about why the SIGKILL occurs. But, this is a bit of a laborious thing to do...

sondr3 commented 8 months ago

I have already done that, it's under the "Details" accordion here

gitperr commented 8 months ago

Yeah, that looks good too. Unfortunately I dunno what might be the issue here. Might be something to do with the compilation as you guys discussed earlier.

sondr3 commented 8 months ago

I copied over and adapted the release pipeline I use for my Rust crates and tested it for this project, and... everything works. The binaries are signed with (ad-hoc,linker-signed) and I can download them via both the browser and terminal tools and run it without problems. Not sure what the problem could be, I used the same version of GHC and macOS, just using the more common YAML pipeline syntax. You can take a look at the pipeline here and try the artifacts here.

tfausak commented 8 months ago

Thanks for investigating! Can you try the assets on the 1.0.2.1 release? Both arm64 and x64 worked for me on my M1 machine.

I'm not entirely sure what the problem was, but I think it was UPX. I removed that. I also ad-hoc signed the binaries with codesign -s - ... (maybe this is unnecessary). See #25 for more info.

sondr3 commented 8 months ago

Works fine now 😄 Could be that it's UPX, yeah. I use strip on my binaries in Rust and haven't had any problems, but maybe UPX is more aggressive.