v1.7.2 (2026-07-27)

Patch release: fixes the release pipeline so the signed macOS Castle Wall app can actually launch. No server-side code changes, no new capability, no breaking changes, no config migration.

Why this release exists

The CI-built macOS app attached to the v1.7.0 and v1.7.1 releases was signed and notarized but could not launch on any Mac. macOS refused to spawn it (“Launchd job spawn failed”, RBS error 5): the binaries claim restricted entitlements (system extension install plus the NetworkExtension content filter provider), and AMFI kills a restricted-entitlement binary whose bundle carries no embedded provisioning profile. Direct execution of the v1.7.1 asset’s host binary dies instantly with SIGKILL.

The local operator build embedded two provisioning profiles before signing, one at Contents/embedded.provisionprofile in the outer app and one inside the nested .systemextension bundle, from files that live on the build machine. The CI workflow had no copy of either file, and the build script’s missing-profile branch printed a warning and kept going. Signing, notarization, stapling, and spctl all pass on a profile-less bundle, so the pipeline had no step that could catch it.

What changed

• The provisioning profiles are committed to the repo at castle-wall-macos/signing/ and embedded before signing in every wrapped build, CI included. A provisioning profile is not a secret: it ships inside every distributed app, is readable by anyone who downloads the release zip, and cannot sign anything. A missing profile is now a hard build failure in wrapped mode instead of a warning, because the output could never launch.
• Fail-closed launchability assertions run before notarization. A new verify-embedded-profiles.sh asserts that both embedded profile placements exist, that every restricted entitlement the signed binaries claim is covered by the embedded profile’s grant, and that codesign --verify --deep --strict passes. Each failure names exactly what is missing. Both the release workflow and the local wrapped build run it.
• A launch smoke test runs on the CI runner after signing and stapling. It direct-executes the host binary under a watchdog and fails loudly on a signal death or exec refusal, which is exactly how the v1.7.0/v1.7.1 defect presents (instant SIGKILL, exit 137).

Install

Install the cooperative Sanctuary CLI:

npx @sanctuary-framework/mcp-server

or explicitly pinned:

npx -y -p @sanctuary-framework/mcp-server@1.7.2 sanctuary

Install the macOS Castle Wall enforcement app from the attached release asset:

• Asset: Sanctuary-CastleWall.app.zip
• SHA-256: 0c09842936ffb9d2d65badd6e00638675fbb91756d0efa1ac2eb6d2032ffb736
• Full install and arm path: Castle Wall macOS install and arm guide

Capability bounds

The smoke test proves the shipped bundle can be spawned and executes application code on a stock macOS CI runner, which is the exact check that killed the v1.7.0/v1.7.1 assets. It does not prove filter enforcement, system extension activation (which needs a one-time console consent), or a GUI launch from Finder; those remain hardware-verified separately. All other macOS Castle Wall bounds are unchanged from v1.7.1: per-uid allow/deny plus attended boot-survival are proven; there is no per-flow rule-attributed audit trail; the hardware re-drill of the combined same-boot plist self-heal is still pending.