TLS 1.2 for Mac OS X 10.6.8 — pre-built binaries

TLS 1.2 for Mac OS X 10.6.8 — pre-built framework + daemon

System-wide TLS 1.2 (AES-GCM, modern EC certificate handling) for Snow Leopard
10.6.8, as ready-to-install binaries. This is a rebuilt Security.framework +
securityd from the mac-os-x-1068 component set with the TLS 1.2 backport. It
replaces the stock 10.6.8 framework, which tops out at TLS 1.0.

Every application that links Security.framework (Safari/WebKit, curl, etc.)
negotiates TLS 1.2 after install — no per-app injection.

To build from source instead, see the repository (BUILDING.md).

What changed in this update (2026-08-04)

Fixes a SIGABRT crash under concurrent HTTPS that previously made WebKit
media playback (YouTube etc.) reliably abort:

EXC_CRASH (SIGABRT) — double free
libcrypto.0.9.8.dylib   CRYPTO_free
libcrypto.0.9.8.dylib   OBJ_NAME_add
libcrypto.0.9.8.dylib   EVP_add_digest
libcrypto.0.9.8.dylib   OpenSSL_add_all_digests
com.apple.security      tls12TrustEvaluateOpenSSL

The TLS 1.2 trust-evaluation and SSL-chain-verify paths called
OpenSSL_add_all_digests() on every invocation with no pthread_once guard
and no OpenSSL 0.9.8 threading callbacks installed. Concurrent trust
evaluations (e.g., WebKit media fetching multiple segments in parallel) raced
in OpenSSL's OBJ_NAME_add, producing the double-free.

Fix: process-wide libcrypto init in tls12_chainverify.c via
tls12_libcrypto_handle(), called by every libcrypto user in the framework
(trust eval, SSL chain verify, SSL key exchange, GCM-AES). Installs
CRYPTO_set_locking_callback + CRYPTO_set_id_callback before any other
libcrypto call; checks existing callbacks before installing (won't clobber
another library's); fails closed on any mutex-init failure.

Verified on a 10.6.8 build host: WebKit YouTube playback that crashed within
seconds before the fix now plays through without SIGABRT.

Likely also addresses the previously-listed "session resumption under
concurrent load" known issue below — OpenSSL's session cache requires the
same locking callbacks this update installs. Worth re-testing; please report
either way.

Assets

File	Size	Arches	SHA-1
Security	13,100,528	x86_64 · i386 · ppc7400	0c5318d961f5f17338a20b6105c56d5f8a7581dd
securityd	2,899,868	x86_64 · i386	570fb9df92ac8a5714b352cb4cb46aae90dc60ee
ssl_anchors.pem	325,840	219 certificates	2359eb44979dfd61c1c92310137713aaf8638e51
install-release.sh	—	installer	—
SHA1SUMS, SHA256SUMS	—	checksums	—

The framework is delivered 3-slice (ppc7400 already grafted), so it drops in
without needing your own stock framework as a ppc donor.

Requirements

• Mac OS X 10.6.8 Snow Leopard
• sudo access; a machine you can fully restore (this replaces a core system framework)

Install

Put all release files in one directory and run:

sudo bash install-release.sh

The installer backs up your stock framework and daemon (first run), stages the
trust anchors, installs the matched pair, rebuilds the dyld shared cache, and
prompts before reboot.

Manual install, if you prefer:

SEC=/System/Library/Frameworks/Security.framework/Versions/A/Security
sudo cp "$SEC" "$(dirname "$SEC")/Security.stock"      # backup framework
sudo cp /usr/sbin/securityd /usr/sbin/securityd.stock  # backup daemon
sudo mkdir -p /usr/local/SecurityPieces
sudo cp ssl_anchors.pem /usr/local/SecurityPieces/     # REQUIRED trust roots
sudo cp Security "$SEC"
sudo cp securityd /usr/sbin/securityd
sudo chown root:wheel "$SEC" /usr/sbin/securityd
sudo chmod 755 "$SEC" /usr/sbin/securityd
sudo update_dyld_shared_cache -force
sudo reboot

The trust-anchor bundle is required

ssl_anchors.pem must be installed to /usr/local/SecurityPieces/. The
framework opens it at that exact path during certificate verification; if it is
missing, TLS certificate validation has no trust roots and fails with
cannot open anchor bundle. Installing the two binaries without the anchor
bundle produces a framework that connects but cannot validate certificates.

The framework and daemon are a matched pair

Install both Security and securityd together. Mixing a new framework with the
stock daemon (or vice-versa) yields CSSMERR_DL_INVALID_DB_HANDLE and the
keychain will not unlock.

Verify

After reboot:

security unlock-keychain -p <pw> ~/Library/Keychains/login.keychain   # returns 0
curl -sS -o /dev/null -w '%{http_code}\n' https://www.google.com      # returns 200

Rollback

The installer saves Security.stock and securityd.stock. To revert (from
single-user mode with Cmd-S if the system won't boot):

SEC=/System/Library/Frameworks/Security.framework/Versions/A/Security
cp "$(dirname "$SEC")/Security.stock" "$SEC"
cp /usr/sbin/securityd.stock /usr/sbin/securityd
rm -f /var/db/dyld/dyld_shared_cache_*
reboot

Known issues

• TLS 1.2 session resumption may have been resolved by the 2026-08-04
  update (which installs the OpenSSL locking callbacks the session cache
  also requires). Previously: intermittent failures under concurrent load —
  a page loads but some parallel subresources fail with what Safari reports
  as "certificate is invalid" (actually errSSLProtocol). If you still see
  this after the update, please open an issue with the system.log excerpt.

Caveats

• 10.6.8 only. Depends on the native 10.6 CSSM/SecureTransport stack and stock
  libcrypto.0.9.8.
• This replaces a core system framework on an obsolete OS. It is a
  preservation/research project — install on a machine you can restore.