cli
cli copied to clipboard
When installed on OSX with Homebrew on Apple Silicon, the sy command fails to load libassuan.0.dylib
Steps to reproduce:
Install Sheesy with on OSX with a recent version of Homebrew:
brew tap share-secrets-safely/cli
brew install sheesy
Then run any command, for example sy --version.
Expected behaviour
The command runs without issues.
Actual behavior
The command fails with:
dyld[2780]: Library not loaded: /usr/local/opt/libassuan/lib/libassuan.0.dylib
Referenced from: <E27503E4-8399-3EE0-8726-E6E09272A3EC> /opt/homebrew/Cellar/sheesy/4.0.10/bin/sy
Reason: tried: '/usr/local/opt/libassuan/lib/libassuan.0.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/usr/local/opt/libassuan/lib/libassuan.0.dylib' (no such file), '/usr/local/opt/libassuan/lib/libassuan.0.dylib' (no such file), '/usr/local/lib/libassuan.0.dylib' (no such file), '/usr/lib/libassuan.0.dylib' (no such file, not in dyld cache)
zsh: abort sy vault list
Note that libassuan is correctly installed on the system (with Homebrew).
The version you were using
The command sy --version crashes, but the installed sy version is 4.0.10.
I am on MacOS Ventura 13.1 on Apple Silicon M1 Max.
The Homebrew version is:
$ brew --version
Homebrew 3.6.20
Homebrew/homebrew-core (git revision 9b06fea8797; last commit 2023-01-17)
Possible explanation
Homebrew on Apple Silicon uses /opt/homebrew as prefix instead of /usr/local (as indicated by the output of brew --prefix and as discussed here), therefore libassuan is located in /opt/homebrew/lib/libassuan.0.dylib. Currently, sy tries to load it from /usr/local and /usr/lib.
Explicitly setting DYLD_LIBRARY_PATH=/opt/homebrew/lib sy --version finds the library, but fails with:
dyld[9043]: Library not loaded: /usr/local/opt/libassuan/lib/libassuan.0.dylib
Referenced from: <E27503E4-8399-3EE0-8726-E6E09272A3EC> /opt/homebrew/Cellar/sheesy/4.0.10/bin/sy
Reason: tried: '/opt/homebrew/lib/libassuan.0.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need 'x86_64')), '/usr/local/opt/libassuan/lib/libassuan.0.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/usr/local/opt/libassuan/lib/libassuan.0.dylib' (no such file), '/usr/local/opt/libassuan/lib/libassuan.0.dylib' (no such file), '/usr/local/lib/libassuan.0.dylib' (no such file), '/usr/lib/libassuan.0.dylib' (no such file, not in dyld cache)
This seems to indicate that the wrong architecture is used when downloading the pre-built sy binary, I suspect because -x86_64 is hardcoded here, and the releases do not include an arm64 version.
Cloning the repo and building it with Cargo produces a working sy binary, so it looks like it is really just an issue with missing pre-built binary for Apple Silicon.
Thanks for this fantastic summary and for digging into understanding the cause.
I second the assessment as to why the pre-built binaries don't work anymore.
This tool hasn't seen any maintenance in years because I don't use it myself anymore, but would love it to have a new maintainer. Would you be interested?
If not, a PR with a fix is definitely welcome and I will do my best to process them to get a new binary release. (It's probably easier to do the respective edits to CI as collaborator as well, so I am offering the position even if it's just temporary)
I am not yet well versed in Rust, but I am happy to contribute at least to fix this issue. I think I can produce the missing binary, and hopefully fix the script here to download the correct one :)
I still use sy in my company, so I am happy to help maintaining it. It might be a good motivation to scale up my Rust skills, and otherwise I have at least one colleague who's really into Rust and could probably help too.
Would it make sense to setup a cross-compilation pipeline on CI like done here to build executables for various architectures? If so, I can give it a try.
Absolutely, that sounds like the proper way of doing it, even though a quick fix is also fine with me as long as it helps you. In any case, you can take it where you need it to be!
I have invited you as a maintainer for all relevant repos, which is merely a starting point for administering the whole 'share secrets safely' organisation if that helps to give sy a future. Once you accept the invite, you should be able to maintain any of the three repositories here.