Properly vendor OpenSSL for aarch64-apple-darwin

[EverlastingBugstopper]

Situation

In Rover v0.1.3 we attempted to remove the OpenSSL runtime dependency for all users (primarily targeting M1 Mac users) by statically linking the necessary OpenSSL APIs right into Rover's binary using the vendored-openssl feature in the git2 dependency.

Problem

Unfortunately, the MacOS machine that we build Rover on is x86_64 and not ARM. This was fine for a bit, since M1 users can install Rosetta 2 to "translate" x86_64 machine code to ARM machine code.

OpenSSL, of course, does not play by the same rules.

If you attempt to run our installer on an M1 machine without Rosetta 2 installed, you'll see a message similar to this:

$ curl -sSL https://rover.apollo.dev/nix/latest | sh
./install.sh: line 84: /var/folders/h_/n6898m3s6znfytgv6l8mh4nh0000gn/T/tmp.rDuMYKvE/rover: Bad CPU type in executable

If you then run softwareupdate --install-rosetta, and then attempt an installation, you'll get a different error message:

$ curl -sSL https://rover.apollo.dev/nix/latest | sh
dyld: Library not loaded: /usr/local/opt/[email protected]/lib/libssl.1.1.dylib
  Referenced from: /var/folders/h_/n6898m3s6znfytgv6l8mh4nh0000gn/T/tmp.qsNTp9uV/rover
  Reason: image not found
sh: line 21: 15601 Abort trap: 6           "$_rover" "install" "$@" < /dev/tty

The working theory here is that the openssl-sys crate decides that it cannot use the vendored OpenSSL code as it was built for a different architecture, so it goes looking for an OpenSSL installation on the end user's machine to use, and when it goes looking for a system installed OpenSSL version and can't find it, it throws this error. This isn't great! I don't think we should make users install and configure OpenSSL just to use Rover (it's a pain I'd rather tackle on our end than to make devs have to worry about configuring).

Unfortunately, neither GitHub Actions nor CircleCI runners work on M1 machines, meaning that automating the build process to actually build Rover for ARM machines is essentially impossible. Eventually, we'll want to build an additional binary with cargo build --release --target aarch64-apple-darwin, and create a universal binary for MacOS with lipo -create -output universal_app x86_rover arm_rover.

Possible Resolution

I'm really hoping that this will be as simple as installing a version of OpenSSL on our x86_64 build machine that will statically link a version of OpenSSL that will work properly with Rosetta 2.

This webpage claims that OpenSSL >=v1.1.170 does work with Rosetta 2! I'm going to attempt to add a step to our release process that installs and uses a newer version of OpenSSL and see if that works.