Context
HTTPClient.pas currently routes HTTPS through FPC's openssl unit on every platform, which dlopens libssl/libcrypto at runtime. That's fine on Linux (where OpenSSL is universally available), but on macOS it pulls in a Homebrew dependency that isn't shipped by Apple, and runs into ABI mismatches: FPC 3.2.2's openssl unit probes for the legacy SSLeay_version symbol that OpenSSL 3 removed (renamed to OpenSSL_version), so on a system with only openssl@3 installed, IsSSLloaded returns false even after dlopen succeeds.
Apple deprecated their bundled OpenSSL years ago and the modern guidance is to use the system TLS stack — Network.framework is the supported successor to the deprecated SecureTransport API.
Proposal
Introduce a small TLS-backend interface in HTTPClient.pas so platforms use their native stack:
{$IF DEFINED(DARWIN)} use Network.framework
{$ELSEIF DEFINED(MSWINDOWS)} use SChannel
{$ELSE} use OpenSSL
{$IFEND}
This keeps Linux on OpenSSL (right answer there — including the Vercel Linux container we deploy the website API binary into) and gets macOS off the Homebrew dependency entirely.
Acceptance criteria
Notes
- Path-of-least-resistance interim: bind
SecureTransport (deprecated since macOS 10.15 but still ships in current OS releases). Long-term: Network.framework via nw_connection_t.
- Once this lands, the
openssl@3 + FPC 3.2.2 symbol-mismatch issue stops affecting macOS users entirely.
Discovered while
Building the website /api/run endpoint that shells out to GocciaScriptLoader. The LocateOpenSSL probe added to source/shared/HTTPClient.pas is a partial mitigation — it sets DLLSSLName/DLLUtilName to absolute Homebrew paths so the right dylib is loaded — but the FPC-3.2.2-vs-OpenSSL-3 symbol issue still bites on systems with only OpenSSL 3 installed.
Context
HTTPClient.pascurrently routes HTTPS through FPC'sopensslunit on every platform, whichdlopenslibssl/libcryptoat runtime. That's fine on Linux (where OpenSSL is universally available), but on macOS it pulls in a Homebrew dependency that isn't shipped by Apple, and runs into ABI mismatches: FPC 3.2.2'sopensslunit probes for the legacySSLeay_versionsymbol that OpenSSL 3 removed (renamed toOpenSSL_version), so on a system with onlyopenssl@3installed,IsSSLloadedreturns false even afterdlopensucceeds.Apple deprecated their bundled OpenSSL years ago and the modern guidance is to use the system TLS stack —
Network.frameworkis the supported successor to the deprecatedSecureTransportAPI.Proposal
Introduce a small TLS-backend interface in
HTTPClient.passo platforms use their native stack:This keeps Linux on OpenSSL (right answer there — including the Vercel Linux container we deploy the website API binary into) and gets macOS off the Homebrew dependency entirely.
Acceptance criteria
HTTPClient.pasexposes a TLS-backend abstraction (connect / read / write / close / verify-host).Network.framework(preferred) orSecureTransport(acceptable interim) — no Homebrew OpenSSL on the macOS code path.opensslunit; the existingLocateOpenSSLlibrary probing stays intact.fetch("https://...")works on a clean macOS install with no Homebrew packages installed.Notes
SecureTransport(deprecated since macOS 10.15 but still ships in current OS releases). Long-term:Network.frameworkvianw_connection_t.openssl@3 + FPC 3.2.2symbol-mismatch issue stops affecting macOS users entirely.Discovered while
Building the website
/api/runendpoint that shells out toGocciaScriptLoader. TheLocateOpenSSLprobe added tosource/shared/HTTPClient.pasis a partial mitigation — it setsDLLSSLName/DLLUtilNameto absolute Homebrew paths so the rightdylibis loaded — but the FPC-3.2.2-vs-OpenSSL-3 symbol issue still bites on systems with only OpenSSL 3 installed.