I recently ran into a very painful problem building an Electron app and using the node-sqlite3 bindings with SQLCipher. When my app was deployed to other macOS computers it would crash hard. After a week of digging, I discovered that I was building the node-sqlite3 bindings against libsqlcipher.a, which was in-turn built against a dynamically linked OpenSSL path from Homebrew (i.e. /usr/local/opt/openssl/lib/libcrypto.dylib). This caused my app to crash on computers that didn’t have OpenSSL installed via Homebrew.
I submitted a PR to homebrew/core that allows SQLCipher users to run brew install sqlcipher --with-static-linking. That new option will build SQLCipher with static linking to OpenSSL so the app is deployable on non-Homebrew/OpenSSL computers. This discrepancy is also mentioned in the building from source instructions here: https://www.zetetic.net/sqlcipher/introduction/
Can I get a +1 and/or feedback on the PR? https://github.com/Homebrew/homebrew-core/pull/33617 Thanks.
Hello @aguynamedben, I took a look over at the pull request. I don’t think there is anything wrong with statically linking, but it seems that the Homebrew maintainers would very much prefer not to add options. Their suggestion to ship the dylib is viable as well (we do the same thing and ship dylibs for some specialized Enterprise Program SQLCipher builds on macOS). You also have the option of using Common Crypto as per your other recent thread.
Thanks for the feedback. I learned over time that getting the linking right with SQLCipher+OpenSSL was so tricky that it wasn’t worth using OpenSSL from Homebrew. I now compile SQLCipher from source against Common Crypto.
With OpenSSL, I was able to get SQLCipher to compile using OpenSSL via static linking (i.e. link libcrypto.a), but when I went on to compile node-sqlite3 bindings everything would appear to work, but encryption would simply not work. I’m happy to help walk through the steps if y’all are every trying to debug macOS+OpenSSL+node-sqlite3 bindings.