Skip to content
This repository has been archived by the owner on Dec 1, 2024. It is now read-only.

macos-arm64 binaries fail to run on macOS M1/2 #66

Closed
05nelsonm opened this issue Mar 15, 2023 · 5 comments · Fixed by #83
Closed

macos-arm64 binaries fail to run on macOS M1/2 #66

05nelsonm opened this issue Mar 15, 2023 · 5 comments · Fixed by #83
Labels
bug Something isn't working

Comments

@05nelsonm
Copy link
Owner

05nelsonm commented Mar 15, 2023

RE: 05nelsonm/kmp-tor#285

Binaries for macos-arm64 are not developer signed and fail signature checks when trying to execute on them. Binaries from the expert bundle worked though which is weird?

Will repackage binaries from each expert bundle and then publish a -SNAPSHOT

@05nelsonm 05nelsonm added the bug Something isn't working label Mar 15, 2023
@05nelsonm
Copy link
Owner Author

05nelsonm commented Mar 16, 2023

Binaries for macOS signed adhoc worked 05nelsonm/kmp-tor#285 (comment)

Signing the binaries breaks reproducibility though. In the interim, will use tor binaries from TorBrowser macOS which are signed with the TorProject's developer ID and run fine. Need to figure out next steps though, as noted in 05nelsonm/kmp-tor#285 (comment)

@05nelsonm
Copy link
Owner Author

There are 3 paths going forward, each with their own trade offs.

  1. Download TorBrowser, extract tor binaries and repackage them
  2. Download tor-expert-bundles, extract binaries, repackage
    • Will need to codesign with developer id the macOS aarch64 and macOS x64 binaries, unless the Tor Project starts
      shipping signed binaries in the expert bundles (still waiting to hear back).
  3. Refactor the build script such that binaries are reproducibly built, and add a signing step such.
    • This will also require a new tool to be developed such that signatures are stripped for the published binaries and compared with the unsigned binaries so library consumers can easily verify by building binaries themselves and comparing with the unsigned binaries.

@05nelsonm
Copy link
Owner Author

Option 2 would be the best, imo, if the Tor Project starts publishing binaries that are codesigned.

Otherwise, I think option 3 would be the most future proof, as it allows for the ability to hack on tor-browser-build's RBM config for reproducible building binaries of platforms/architectures that TorBrowser doesn't currently support.

@05nelsonm
Copy link
Owner Author

05nelsonm commented Mar 16, 2023

Looks like Option 3 it is, using the tool referenced in the below comment.

05nelsonm/kmp-tor#285 (comment)

@05nelsonm
Copy link
Owner Author

05nelsonm commented Mar 16, 2023

Binary build process needs to be refactored into 3 steps:

  1. Build binaries via tor-browser-build and extract to an unsigned directory
  2. Sign all binary files creating detached signatures
  3. Apply detached signatures and gzip binaries, copying them to their respective kmp-tor-binary-* resource directories.

Binary verification process (for library consumers):

  1. Clone repo
  2. Run binary build script (git diff should show no changes after consumer built binaries were moved to the unsigned directory)
  3. Run sign/gzip script (git diff should show no changes after consumer applied detached codesign signatures, gzipped files, and moved them to their respective resource directory).

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant