OSX/MacOS arm64 version of squidex command line client is killed upon launch on macOS terminal

I have…

  • Checked the logs and have uploaded a log file and provided a link because I found something suspicious there. Please do not post the log file in the topic because very often something important is missing.

I’m submitting a…

  • Regression (a behavior that stopped working in a new release)
  • Bug report
  • Performance issue
  • Documentation issue or request

Current behavior

Running ./sq command in terminal client for arm64 on MacOS exits with status: “killed”

Expected behavior

Running ./sq command should print parameters and options to be passed to the command

Minimal reproduction of the problem

  1. Downloaded: https://github.com/Squidex/squidex-samples/releases/download/cli-v13.0/osx-arm64.zip

  2. unzipped osx-arm64.zip

  3. Tried to run “./sq” in the same directory as where the sq binary file is located.

  4. Command terminated with “killed” status

  5. (Workaround)

Double checked with the x64 version of the binary file, to see if Rosetta 2 could utilize it:
https://github.com/Squidex/squidex-samples/releases/download/cli-v13.0/osx-x64.zip

Followed steps 1-4 above.

Worked to use the x64 version through Rosetta 2 in the MacOS terminal client.

So it seems that on Mac OS with an M apple silicon processor, only the arm version is affected

Environment

  • MacOS Sonoma 14.4.1 - MacBook Pro 13" inch 2022 version.
  • regular ZSH based terminal in Sonoma

Interesting. I do not have a Mac, so I am not sure, if I can solve that myself. Do you get any kind of details, like error message from the OS or something like that?

Thanks for your swift answer :slight_smile:

Hmm…Can´t see any more log output than that the process was swiftly killed, but I’ll let you know if I find any.

Hmmmm…nothing in system.log either as far as I can see…

T

1 Like

Ah, think I found it.

Console.log on macOS shows, for the ARM version of the sq binary:

ASP: Security policy would not allow process: 76630, /Users/terje/squidex-cli/sq

This means that the SIP protection kicked in, not allowing the binary to be executed. You may have to sign the app somehow to allow it through the SIP gatekeeper automatically, without end users having to meddle with SIP settings manually.

ChatGPT rudimentarily outlines the process here:

To sign a binary file for macOS so that it can pass through Gatekeeper and System Integrity Protection (SIP), you'll need to obtain an Apple Developer ID certificate and use it to sign the binary. Here's a step-by-step guide:

1. **Obtain an Apple Developer ID certificate**:
   - If you don't already have an Apple Developer account, you'll need to create one on the [Apple Developer](https://developer.apple.com/) website.
   - Once logged in to your developer account, navigate to the Certificates, Identifiers & Profiles section.
   - Follow the instructions to create a Developer ID Application certificate. This certificate will allow you to sign applications and binaries for distribution outside of the Mac App Store.

2. **Export the Developer ID certificate**:
   - After obtaining the Developer ID certificate, export it from your keychain to a file:
     - Open the Keychain Access application on your Mac.
     - Select the "Certificates" category on the left sidebar.
     - Find your Developer ID Application certificate in the list.
     - Right-click on the certificate and choose "Export".
     - Choose a file format (`.p12` is common) and provide a password to protect the exported certificate.

3. **Convert the exported certificate to a PEM format** (optional):
   - You may need to convert the exported certificate to a PEM format if you're using certain tools to sign the binary. You can use the `openssl` command-line tool to perform the conversion:
     ```bash
     openssl pkcs12 -in exported_certificate.p12 -out developer_id_certificate.pem -nodes
     ```

4. **Sign the binary with the Developer ID certificate**:
   - Use the `codesign` command-line tool to sign the binary with the Developer ID certificate:
     ```bash
     codesign --deep --force --sign "Developer ID Application: Your Developer Name" /path/to/your/binary
     ```
     Replace "Developer ID Application: Your Developer Name" with the name of your Developer ID certificate, and replace "/path/to/your/binary" with the path to the binary you want to sign.
     - The `--deep` option ensures that all nested components of the binary are signed.
     - The `--force` option forces signing even if the binary is already signed.
   
5. **Verify the signature**:
   - After signing the binary, you can verify the signature using the `codesign` tool:
     ```bash
     codesign --verify --verbose=4 /path/to/your/binary
     ```
     This command will display information about the signature status and any errors or warnings encountered during verification.

6. **Notarize the application** (optional, but recommended):
   - Notarization is an additional step to ensure that your application passes through Gatekeeper and is trusted by macOS. It involves submitting your application to Apple for review and approval. You can notarize your application using Xcode or the `xcrun altool` command-line tool.

By signing your binary with a Developer ID certificate and optionally notarizing it, you can ensure that it passes through Gatekeeper and SIP on macOS systems without triggering security warnings or being blocked.
1 Like

Yes, I think I am not doing that for now.

There is a new ARM image. It might be fixed now.

I’ve tried a newer version released two weeks ago, but I’m encountering the same issue. Here is my environment and device information:

Environment

  • MacBook Pro(chip Apple M1 Pro) 14" 2021, MacOS Sonoma 14.6.1
  • regular ZSH based terminal in Sonoma

Current behavior

Running ./sq command in terminal client for arm64 on MacOS exits with status: “killed”

./sq
zsh: killed     ./sq

I cannot really test it and I need help with that. Not that much I can at the moment.

I can try it again the next time in that project :slight_smile:

But previously we did the workaround outlined initially in this thread; “Worked to use the x64 version through Rosetta 2 in the MacOS terminal client.” - basically emulating x64 on MacOS through Rosetta 2. That worked for us, so @mappr you might be able to do that as well.

2 Likes

Thank you @Terje_K_L_Thoresen that worked :wink:

1 Like