Skip to content

0.18.3: the macOS binary runs under the hardened runtime - #82

Merged
rmichaelthomas merged 1 commit into
mainfrom
release/0-18-3
Sep 28, 2026
Merged

rmichaelthomas merged 1 commit into
mainfrom
release/0-18-3

Conversation

@rmichaelthomas

Copy link
Copy Markdown
Owner

0.18.2's liminate-macos-arm64 exits before running anything on current macOS:

Failed to load Python shared library '…/_MEI…/Python': … code signature … not valid for use in process:
mapping process and mapped file (non-platform) have different Team IDs

The binary is signed with our Developer ID and the hardened runtime, but the Python.framework inside the one-file archive kept its original team's signature, so library validation refuses to load it. codesign --verify passes, which is why the release looked fine.

Fix

  • build/build_macos_release.sh: PyInstaller with --codesign-identity, which signs every collected binary with our identity. It then signs the outer binary and runs the built binary (--version and examples/program1_basics.limn).
  • release.yml: import the certificate before the build, then call the script. The release job sets overwrite_files: false.
  • RELEASING.md: why the recipe signs collected binaries, and a "When Actions can't run" path.
  • 0.18.3 version bump and fixture rename, following the 0.18.2 convention. No language change.

Evidence

  • The binary this script builds runs with library validation on, standalone and inside a signed CueCue.app after being re-signed with CueCue's own entitlements (the way Tauri's bundler treats an externalBin).
  • 1753 passed, 2 skipped on Python 3.12, and grammar_gen.py --check is clean.

Why now: CueCue's floor (the pre-publish check) runs Liminate as a bundled sidecar, and needs a macOS binary that starts under the hardened runtime without switching library validation off.

Release plan (Actions is billing-blocked): merge, tag v0.18.3, and attach the macOS binary built by this script, notarized by hand. When Actions is back, re-run the tag's Release workflow. It adds Linux, Windows and PyPI and leaves the macOS asset alone, so CueCue's SHA-256 pin stays valid.

🤖 Generated with Claude Code

https://claude.ai/code/session_01PqrbVBAmoTQETg9Yc6aXzz

0.18.2's liminate-macos-arm64 can't start. It is signed with our
Developer ID and the hardened runtime, but the Python.framework it
unpacks at launch kept its original team's signature, and library
validation refuses it: "mapping process and mapped file (non-platform)
have different Team IDs". codesign --verify passed, so nothing caught it.

PyInstaller now signs everything it collects (--codesign-identity), which
means the certificate is imported before the build instead of after.
build/build_macos_release.sh holds the build, sign and a run of the built
binary; the workflow calls it, and so can a local release. A binary built
this way runs with library validation on, including after an app bundler
re-signs it with the app's own entitlements (checked in a signed CueCue
bundle).

Actions can't run right now, so the macOS asset for this tag is released
by hand with that script (RELEASING.md, "When Actions can't run"). The
release job no longer replaces an asset that is already there, so
re-running the workflow later adds Linux, Windows and PyPI without
changing the macOS binary CueCue pins.

No language change. The fixture is renamed for the version, as before.
1753 passed, 2 skipped on Python 3.12; grammar projections up to date.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PqrbVBAmoTQETg9Yc6aXzz
@rmichaelthomas
rmichaelthomas merged commit 863317a into main Sep 28, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant