Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Diferentiate between Intel and ARM in macOS packages #5913

Open
DFolchA opened this issue Feb 9, 2023 · 4 comments
Open

Diferentiate between Intel and ARM in macOS packages #5913

DFolchA opened this issue Feb 9, 2023 · 4 comments

Comments

@DFolchA
Copy link
Contributor

DFolchA commented Feb 9, 2023

On the packages list page, the macOS packages are indicated as 64bits. This may be confusing for the user because the term 64bits is used in both Intel and ARM architectures.

image

We need to specify that the packages are Intel based and clarify that they can be used in Apple Silicon systems through the use of Rosetta.

@sempervictus
Copy link

Its actually not entirely clear that this even works on M1 macs - i get the sense that TCC doesn't permit it to read inside user directories on those, though thats anecdotal.
@vikman90 - do you happen to know who owns the mac agent side of the effort, and if so, could you possibly flag this ticket for their attention? I think there are some things that might need fixing on the mac side both in terms of silicon and OS restrictions around the agent itself.

@DFolchA DFolchA changed the title Diferentiate between Intel and ARM in MacOS packages Diferentiate between Intel and ARM in macOS packages Feb 23, 2023
@vikman90
Copy link
Member

Hi @sempervictus, we had permission-related issues on macOS since Catalina (wazuh/wazuh-qa#217) that we managed to fix by notarizing our package (wazuh/wazuh-packages#316).

However, we plan to provide a native agent for M1:

Best!

@giladreich
Copy link

Commenting just for the record, as there was nothing mentioned about universal FAT binaries: wazuh/wazuh-dashboard-plugins#5202 (comment)

Note that from my experience the notarytool is dealing well with FAT binaries and there is no need to notarizing them individually, rather just the final binary that was lipoed with multiple architectures and lastly codesign.

@giladreich
Copy link

giladreich commented May 30, 2023

Here is a snippet how I did it from a GH Action after the final FAT binary was produced with lipo (I would never recommend using this in a public repo to avoid pipeline poisoning attacks):

      - name: Notarize & Codesign
        run: |
          set -ex
          echo -n "${{ secrets.CERT_P12 }}" | base64 --decode -o cert.p12
          security create-keychain -p "${{ secrets.KEYCHAIN_PWD }}" build.keychain
          security default-keychain -s build.keychain
          security unlock-keychain -p "${{ secrets.KEYCHAIN_PWD }}" build.keychain
          security import cert.p12 -k build.keychain -P "${{ secrets.CERT_P12_PWD }}" -T /usr/bin/codesign
          security set-key-partition-list -S apple-tool:,apple:,codesign: -s -k "${{ secrets.KEYCHAIN_PWD }}" build.keychain

          xcrun notarytool store-credentials "notarytool-profile" \
            --apple-id "my.apple.id@email.com" \
            --team-id "${{ secrets.APP_TEAM_ID }}" \
            --password "${{ secrets.APP_SPECIFIC_PWD }}"

          /usr/bin/codesign --force -s "${{ secrets.IDENTITY_ID }}" --options runtime path/to/binary -v
          zip -r binary-submit.zip path/to/binary
          xcrun notarytool submit binary-submit.zip --keychain-profile "notarytool-profile" --wait
          # xcrun notarytool log $uuid --keychain-profile "notarytool-profile"

/cc @vikman90

EDIT: I see you already have it implemented part of a shell script.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants