TLS 1.2 for Snow Leopard (10.6.8) — System-Wide Security.framework Rebuild
What this is
A source-level backport that brings system-wide TLS 1.2 (with AES-GCM and modern EC certificate handling) to Mac OS X 10.6.8 by rebuilding Apple's Security.framework and its securityd daemon from the open-source mac-os-x-1068 component set. No per-app dylib injection, no DYLD_INSERT_LIBRARIES — every app that links Security.framework (Safari/WebKit, curl, etc.) negotiates TLS 1.2.
The stock 10.6.8 framework tops out at TLS 1.0 and can't validate many current certificate chains. This replaces it.
Mostly an AI job.
Repo
https://github.com/startergo/tls12-snow-leopard-merge
Pre-release
https://github.com/startergo/tls12-snow-leopard-merge/releases
Prerequisites
The repo is self-contained for build inputs — no MacPorts, no network fetches, no external source downloads (ANTLR runtime, trust anchors, and all SDK-absent headers are vendored). But it needs a properly configured host:
Test on a machine you can fully restore. This replaces a core system framework. Keep the recovery commands the installer prints.
Build
From the repository root — two stages, both architectures required:
VM defaults to the script's own directory, so setting it is optional when you run from the repo root. ARCHES='x86_64 i386' is required — an x86_64-only build fails at the daemon link (the per-arch client frameworks are built in the i386 chain).
A successful run ends with resolved 26/26 archives for each arch, FAT daemon OK, and produces Security.fat.new + dst-securityd-fat/securityd (both 2-slice; ppc7400 is grafted at install).
If your sudo needs a password non-interactively (e.g. over SSH), set VM_SUDO_PASS in the environment or copy config.sh.example to config.sh and set it there (config.sh is git-ignored).
Install
The framework and daemon are a matched pair and must be installed together. The script grafts the ppc7400 slice from stock (→ 3-slice), installs both, rebuilds the dyld shared cache, then tests the new framework in place (keychain unlock + HTTPS) and shows PASS/FAIL before prompting for reboot (defaults to No). On failure it prints a no-reboot rollback so a bad build never has to be booted. It prints single-user recovery commands — note them down.
Verify
After reboot:
To exercise the TLS 1.2 path directly (the included test program links -framework Security):
What to report
Known issue: TLS 1.2 session resumption fails intermittently under concurrent load — page loads but some subresources (fonts, JS, images) fail with what Safari reports as "certificate is invalid" (actually errSSLProtocol). Most visible on https://www.bbc.co.uk/news with many parallel subresource requests to CDN hosts. Fresh handshakes are unaffected. If you can reproduce this reliably on specific sites, that data is especially useful.
Caveats
Thanks for testing. Build logs and the exact failing command are worth more than "it didn't work" — paste what you see.
What this is
A source-level backport that brings system-wide TLS 1.2 (with AES-GCM and modern EC certificate handling) to Mac OS X 10.6.8 by rebuilding Apple's Security.framework and its securityd daemon from the open-source mac-os-x-1068 component set. No per-app dylib injection, no DYLD_INSERT_LIBRARIES — every app that links Security.framework (Safari/WebKit, curl, etc.) negotiates TLS 1.2.
The stock 10.6.8 framework tops out at TLS 1.0 and can't validate many current certificate chains. This replaces it.
Mostly an AI job.
Repo
https://github.com/startergo/tls12-snow-leopard-merge
Pre-release
https://github.com/startergo/tls12-snow-leopard-merge/releases
Prerequisites
The repo is self-contained for build inputs — no MacPorts, no network fetches, no external source downloads (ANTLR runtime, trust anchors, and all SDK-absent headers are vendored). But it needs a properly configured host:
- Mac OS X 10.6.8 — the build must run on Snow Leopard itself
- Xcode 4.1 with the 10.6 SDK at /Developer/SDKs/MacOSX10.6.sdk (4.2 may work per xcodereleases.com; 4.1 is what's tested — not 3.2.x)
- llvm-gcc-4.2 — the required compiler (not clang), plus lipo and xcodebuild
- Stock /usr/lib/libcrypto.0.9.8.dylib — ships with 10.6; the EC/RSA fallback dlsyms from it
- For install: a genuine stock 10.6.8 Security.framework on the target (the ppc7400 slice is grafted from it)
- ~2 GB free and sudo access
Test on a machine you can fully restore. This replaces a core system framework. Keep the recovery commands the installer prints.
Build
From the repository root — two stages, both architectures required:
Code:
VM="$(pwd)" STAGE=bootstrap bash build-consistent-framework.sh
VM="$(pwd)" STAGE=all ARCHES='x86_64 i386' bash build-consistent-framework.shVM defaults to the script's own directory, so setting it is optional when you run from the repo root. ARCHES='x86_64 i386' is required — an x86_64-only build fails at the daemon link (the per-arch client frameworks are built in the i386 chain).
A successful run ends with resolved 26/26 archives for each arch, FAT daemon OK, and produces Security.fat.new + dst-securityd-fat/securityd (both 2-slice; ppc7400 is grafted at install).
If your sudo needs a password non-interactively (e.g. over SSH), set VM_SUDO_PASS in the environment or copy config.sh.example to config.sh and set it there (config.sh is git-ignored).
Install
Code:
bash install-consistent-and-reboot.shThe framework and daemon are a matched pair and must be installed together. The script grafts the ppc7400 slice from stock (→ 3-slice), installs both, rebuilds the dyld shared cache, then tests the new framework in place (keychain unlock + HTTPS) and shows PASS/FAIL before prompting for reboot (defaults to No). On failure it prints a no-reboot rollback so a bad build never has to be booted. It prints single-user recovery commands — note them down.
Verify
After reboot:
Code:
security unlock-keychain -p <pw> ~/Library/Keychains/login.keychain -> rc 0
curl -sS -o /dev/null -w '%{http_code}\n' https://www.google.com -> 200To exercise the TLS 1.2 path directly (the included test program links -framework Security):
Code:
gcc -arch x86_64 -o /tmp/ssltest ssltest.c -framework Security -framework CoreFoundation
/tmp/ssltest www.google.com 443What to report
- Build host: exact Xcode version, whether the 10.6 SDK is at the standard path
- Build result: did you get 26/26 both arches? Any BUILD ISSUE or ABORT lines — paste them
- Install: did the in-place test pass (keychain rc=0, HTTPS 200)? Did it boot cleanly?
- Real-world use: which HTTPS sites work / fail in Safari, curl, etc.
Known issue: TLS 1.2 session resumption fails intermittently under concurrent load — page loads but some subresources (fonts, JS, images) fail with what Safari reports as "certificate is invalid" (actually errSSLProtocol). Most visible on https://www.bbc.co.uk/news with many parallel subresource requests to CDN hosts. Fresh handshakes are unaffected. If you can reproduce this reliably on specific sites, that data is especially useful.
Caveats
- Builds from a clean clone and works, but the binary may not be byte-identical across hosts (compiler/path differences perturb it — behavior is unaffected)
- 10.6.8 only — depends on the native 10.6 CSSM/SecureTransport and stock libcrypto 0.9.8
- This is a preservation/research project for an obsolete OS that replaces a core system framework — treat it accordingly
Thanks for testing. Build logs and the exact failing command are worth more than "it didn't work" — paste what you see.
Last edited:
