Bug: darwin-arm64 prebuilt lbugjs.node hardcodes Homebrew OpenSSL paths — dlopen fails on Macs without Homebrew (regression from 0.15.3)

[alejandrodgb]

Ladybug version

@ladybugdb/core 0.18.1 (npm prebuilt, darwin-arm64)

What operating system are you using?

macOS (Darwin 25.3.0, Apple Silicon), no Homebrew — OpenSSL via MacPorts

What happened?

Ladybug version

@ladybugdb/core 0.18.1 (npm prebuilt, darwin-arm64)

Operating system

macOS (Darwin 25.3.0, Apple Silicon) — without Homebrew (OpenSSL via MacPorts)

What happened?

The darwin-arm64 prebuilt lbugjs.node published to npm dynamically links OpenSSL at Homebrew's absolute install paths:

$ otool -L node_modules/@ladybugdb/core/lbugjs.node | grep ssl
	/opt/homebrew/opt/openssl@3/lib/libssl.3.dylib (compatibility version 3.0.0, current version 3.0.0)
	/opt/homebrew/opt/openssl@3/lib/libcrypto.3.dylib (compatibility version 3.0.0, current version 3.0.0)

On any Mac that doesn't have Homebrew installed (MacPorts users, or machines with no package manager at all), the native module fails to load:

dlopen(.../@ladybugdb/core/lbugjs.node, 0x0001): Library not loaded: /opt/homebrew/opt/openssl@3/lib/libssl.3.dylib
  Reason: tried: '/opt/homebrew/opt/openssl@3/lib/libssl.3.dylib' (no such file), ...

This is a regression: the 0.15.3 darwin-arm64 prebuilt was self-contained — it linked only system libraries (libSystem.B.dylib, libc++.1.dylib) with no OpenSSL dependency at all, and loaded fine on the same machine.

Expected: the npm prebuilt loads on a stock macOS install, without assuming Homebrew is present. Options that would achieve that: statically link OpenSSL into the prebuilt (as 0.15.3 effectively behaved), or bundle the dylibs and reference them via @rpath/@loader_path.

Downstream impact: any npm consumer of @ladybugdb/core is broken on Homebrew-less Macs (I hit this via gitnexus).

Workarounds I verified, for anyone else who lands here:

# Per-copy binary patch (no sudo):
install_name_tool \
  -change /opt/homebrew/opt/openssl@3/lib/libssl.3.dylib    /opt/local/lib/libssl.3.dylib \
  -change /opt/homebrew/opt/openssl@3/lib/libcrypto.3.dylib /opt/local/lib/libcrypto.3.dylib \
  path/to/lbugjs.node
codesign -f -s - path/to/lbugjs.node

# Or a system-wide shim (survives reinstalls):
sudo mkdir -p /opt/homebrew/opt/openssl@3/lib
sudo ln -s /opt/local/lib/libssl.3.dylib    /opt/homebrew/opt/openssl@3/lib/
sudo ln -s /opt/local/lib/libcrypto.3.dylib /opt/homebrew/opt/openssl@3/lib/

Are there known steps to reproduce?

On an Apple Silicon Mac without /opt/homebrew:

npm i @ladybugdb/core@0.18.1
node -e "require('@ladybugdb/core')"   # dlopen failure above
otool -L node_modules/@ladybugdb/core-darwin-arm64/lbugjs.node   # shows the hardcoded Homebrew paths

Installing @ladybugdb/core@0.15.3 on the same machine works (its lbugjs.node has no OpenSSL linkage).

[adsharma]

I don't know what the solution is. But stating some positions here:

• Shipping ladybug without openssl is not feasible. Enables an attacker to do man in the middle attacks when installing extensions. Untrusted code.

• Do not want to bundle openssl3 into ladybug. This is a security sensitive library. Any time there is a CVE, we'll have to spin up a new version of ladybug. Don't have the resources.

If you have openssl3 installed somewhere else with proper security updates (highly recommended), happy to add that path.

[100yenadmin]

Additional darwin-arm64 confirmation from a downstream RC19 dependency comparison:

• @ladybugdb/core@0.18.1 loads on this Apple Silicon host because Homebrew OpenSSL is installed.
• otool -L node_modules/@ladybugdb/core/lbugjs.node still reports absolute dependencies:
  • /opt/homebrew/opt/openssl@3/lib/libssl.3.dylib
  • /opt/homebrew/opt/openssl@3/lib/libcrypto.3.dylib
• The same focused native/checkpoint/adapter set passed 50/50 tests on both 0.18.0 and 0.18.1 here.
• This host cannot validate a Homebrew-free configuration, so that job remains a required matrix gate rather than being inferred from the passing local load.

No duplicate issue was filed.

[100yenadmin]

Correction/additional evidence: the RC19-pinned @ladybugdb/core@0.18.0 darwin-arm64 binary has the same absolute Homebrew OpenSSL dependencies as 0.18.1:

• /opt/homebrew/opt/openssl@3/lib/libssl.3.dylib
• /opt/homebrew/opt/openssl@3/lib/libcrypto.3.dylib

Both versions load on the current Apple Silicon host because Homebrew OpenSSL exists, and both pass the focused checkpoint/native set. Neither version satisfies the downstream non-Homebrew portability gate as currently packaged. We are therefore retaining 0.18.0 only as an RC laboratory pin, not accepting it as promotion-safe.

[100yenadmin]

Cross-platform downstream comparison is now complete:

• GitNexus RC19 with published Ladybug 0.18.0: https://github.com/electricsheephq/evaOS-gitnexus/actions/runs/29226560630
• the same RC19 tree with exact published Ladybug 0.18.1: https://github.com/electricsheephq/evaOS-gitnexus/actions/runs/29226591207

Every Ladybug-relevant native/platform-sensitive and packaged-install job passed on Ubuntu, Windows, and macOS for both versions. The two failed assertions in each run are unrelated GitNexus plugin-version drift. No 0.18.1-specific checkpoint/native regression appeared.

Portability remains open because the published darwin binaries still encode absolute Homebrew OpenSSL paths. PR #682 ordinary checks are now fully green; the remaining acceptance evidence is its no-publish macOS ARM/Intel Node artifact workflow dispatch.