J124: signed and notarized arm64 macOS CLI and capture helper

kayg commented

2026-11-03 06:08:38 +00:00

Owner

Goal

Ship an arm64 macOS infraternal CLI/agent built with remote,desktop, plus InfraternalCaptureHelper.app, signed with the owner's Apple Developer ID and notarized, so app-window capture can be tried against production. [D321]

Plan and estimate (3 hours)

Read D321/D204/D205/D213, the desktop helper builder and release packager; inspect #146 and coordinate the Mac-node slot with #265 (30 min).
Make the Mac release script reproducible and secret-safe, build/sign/notarize/staple/verify on the Mac VM, and collect the artifacts and checksums (90 min).
Update #146 owner test steps, publish a pre-release asset, and post links/checksums and verification evidence here (30 min).
Run scripts/verify fast on an available build VM and report its output (30 min).

Constraints

Use the pre-existing dedicated signing keychain and 1Password service account on the Mac VM only. Never access the login keychain or TCC database. Keep credentials out of argv, logs, and the repository. Do not push to dev/main or deploy.

## Goal Ship an arm64 macOS infraternal CLI/agent built with `remote,desktop`, plus `InfraternalCaptureHelper.app`, signed with the owner's Apple Developer ID and notarized, so app-window capture can be tried against production. [D321] ## Plan and estimate (3 hours) 1. Read D321/D204/D205/D213, the desktop helper builder and release packager; inspect #146 and coordinate the Mac-node slot with #265 (30 min). 2. Make the Mac release script reproducible and secret-safe, build/sign/notarize/staple/verify on the Mac VM, and collect the artifacts and checksums (90 min). 3. Update #146 owner test steps, publish a pre-release asset, and post links/checksums and verification evidence here (30 min). 4. Run `scripts/verify fast` on an available build VM and report its output (30 min). ## Constraints Use the pre-existing dedicated signing keychain and 1Password service account on the Mac VM only. Never access the login keychain or TCC database. Keep credentials out of argv, logs, and the repository. Do not push to dev/main or deploy.

kayg commented

2026-11-03 06:08:53 +00:00

Author

Owner

Started in branch j124-signed-macos at base 7add126405a9205bb817a154af11fad2c438cd45. Plan and 3-hour estimate are in this issue body. I am continuing the existing J124 worktree and will record findings/evidence and the final head/gate output here.

Started in branch `j124-signed-macos` at base `7add126405a9205bb817a154af11fad2c438cd45`. Plan and 3-hour estimate are in this issue body. I am continuing the existing J124 worktree and will record findings/evidence and the final head/gate output here.

kayg commented

2026-11-03 06:10:34 +00:00

Author

Owner

Findings: (1) At base 7add126405a9205bb817a154af11fad2c438cd45, scripts/package-release builds the server with default features; the existing #146/J123 receipt confirms desktop is absent, so production needs a desktop-enabled server build before the artifact can open app windows. I will call this out in the owner steps rather than silently changing deployment scope. (2) The initial handoff lock probe accidentally created a zero-byte file at /tmp/mac-bench.lock before discovering macOS lacks flock; I will clear it under a bounded lockf guard and use the release script's directory lock. The keychain cleanup is complete: the explicitly named infraternal-signing.keychain-db is locked. No login keychain or TCC access occurred.

Findings: (1) At base `7add126405a9205bb817a154af11fad2c438cd45`, `scripts/package-release` builds the server with default features; the existing #146/J123 receipt confirms `desktop` is absent, so production needs a desktop-enabled server build before the artifact can open app windows. I will call this out in the owner steps rather than silently changing deployment scope. (2) The initial handoff lock probe accidentally created a zero-byte file at `/tmp/mac-bench.lock` before discovering macOS lacks `flock`; I will clear it under a bounded `lockf` guard and use the release script's directory lock. The keychain cleanup is complete: the explicitly named `infraternal-signing.keychain-db` is locked. No login keychain or TCC access occurred.

kayg commented

2026-11-03 06:17:53 +00:00

Author

Owner

1Password/notarization finding: op is installed on the Mac VM, and the service-account token file is mode 0600. The service account can see one vault, Apps / Infraternal; its certificate item is Apple Certificates and includes Developer ID Application.p12. No App Store Connect API key or Apple ID app-specific password item was found in that accessible vault. After securely unlocking and then relocking only infraternal-signing.keychain-db, notarytool history with profile infraternal-notary exited nonzero. I have not exposed any credential values. I can continue repo work and the Linux gate while waiting for the notary item name/access or a usable dedicated-keychain profile.

1Password/notarization finding: `op` is installed on the Mac VM, and the service-account token file is mode 0600. The service account can see one vault, `Apps / Infraternal`; its certificate item is `Apple Certificates` and includes `Developer ID Application.p12`. No App Store Connect API key or Apple ID app-specific password item was found in that accessible vault. After securely unlocking and then relocking only `infraternal-signing.keychain-db`, `notarytool history` with profile `infraternal-notary` exited nonzero. I have not exposed any credential values. I can continue repo work and the Linux gate while waiting for the notary item name/access or a usable dedicated-keychain profile.

kayg commented

2026-11-03 06:21:14 +00:00

Author

Owner

Lock correction: the stray zero-byte regular file is removed under a bounded lockf guard. The /tmp/mac-bench.lock path is clear for the release script's bounded directory lock. Short Mac 1Password metadata checks held/released that lock; no build/signing run has started.

Lock correction: the stray zero-byte regular file is removed under a bounded `lockf` guard. The `/tmp/mac-bench.lock` path is clear for the release script's bounded directory lock. Short Mac 1Password metadata checks held/released that lock; no build/signing run has started.

kayg commented

2026-11-03 06:29:00 +00:00

Author

Owner

Gate setup finding: I checked both VM queues and selected dev-02 (two busy slots vs four on compute01). Its shallow HTTPS clone into ~/worktrees/j124-signed-macos is stuck in uninterruptible D state on wait_on_buffer; /proc/850663/io showed 20,480 bytes read and zero bytes written after 3m21s. I sent TERM then KILL to this exact clone PID; it remains in the kernel wait. No gate/build has started. I will wait for that I/O to clear and retry with the repo's rsync snapshot option; no other job or worktree has been touched.

Gate setup finding: I checked both VM queues and selected dev-02 (two busy slots vs four on compute01). Its shallow HTTPS clone into `~/worktrees/j124-signed-macos` is stuck in uninterruptible `D` state on `wait_on_buffer`; `/proc/850663/io` showed 20,480 bytes read and zero bytes written after 3m21s. I sent TERM then KILL to this exact clone PID; it remains in the kernel wait. No gate/build has started. I will wait for that I/O to clear and retry with the repo's rsync snapshot option; no other job or worktree has been touched.

kayg commented

2026-11-03 06:30:06 +00:00

Author

Owner

Progress: added and committed the release script as b8fe43d82 on j124-signed-macos (base 7add126405a9205bb817a154af11fad2c438cd45). bash -n and git diff --check pass. The required full gate is next; Mac notarization remains blocked on the service account's missing credential item or a usable profile name.

Progress: added and committed the release script as `b8fe43d82` on `j124-signed-macos` (base `7add126405a9205bb817a154af11fad2c438cd45`). `bash -n` and `git diff --check` pass. The required full gate is next; Mac notarization remains blocked on the service account's missing credential item or a usable profile name.

kayg commented

2026-11-03 06:44:20 +00:00

Author

Owner

Progress update: current local branch head is eb5939013b4ee977aeb8ce77c2c8876d4a8bab21 (base 7add126405a9205bb817a154af11fad2c438cd45). The exact tracked source tree plus release script is on compute01; scripts/verify fast is waiting in build-slot queue position 5 (log: ~/.cache/codex-scratch/J124/evidence/verify-fast.log). Mac notarization is still waiting for a credential item/access or a usable profile name.

Progress update: current local branch head is `eb5939013b4ee977aeb8ce77c2c8876d4a8bab21` (base `7add126405a9205bb817a154af11fad2c438cd45`). The exact tracked source tree plus release script is on compute01; `scripts/verify fast` is waiting in build-slot queue position 5 (log: `~/.cache/codex-scratch/J124/evidence/verify-fast.log`). Mac notarization is still waiting for a credential item/access or a usable profile name.

kayg commented

2026-11-03 10:09:29 +00:00

Author

Owner

Takeover (J124c, Sonnet 5.5) — the previous Codex job stopped on a provider rate limit; I continue from its work, nothing is restarted.

State found:

Branch j124-signed-macos exists only locally (never pushed), head eb5939013, base 7add12640 (origin/dev is now 29 commits ahead). One commit: scripts/macos-release. Its worktree is clean; no uncommitted work, nothing to rescue.
compute01 holds only a gate snapshot (~/worktrees/j124-signed-macos, branch master, commits c63c758/cd42339); its verify-fast.log there ends VERIFY_EXIT=0 but for a snapshot, not this branch head, so I treat it as no evidence. dev-02 has an empty worktree at the base.
No J124 processes are left on either VM (the running jobs belong to j129, j130, m128 and others). Mac: /tmp/mac-bench.lock absent, nothing running.
Re-checked 1Password just now (metadata only, under the lock): the service account still sees one vault with three items (Apple Certificates, Infraternal Release Token, Infraternal / Cloudflare Token), active and archived. There is still no notarization credential. Notarization stays blocked on the owner.

Plan (own branch j124c-signed-macos from eb5939013, then rebased on origin/dev):

Review fixes to the script (30 min): the env var is misspelled INFRATERAL_NOTARY_PROFILE; the lock is a mkdir directory, which does not exclude a flock(2) holder on the same path (macOS has no flock binary), so use BSD lockf on the file, which is flock(2)-compatible.
Add a --skip-notarize mode (smallest change that lets me prove the build and signing now): build, sign, codesign --verify --strict on the Mac. Output is named UNNOTARIZED and is not a release (45–90 min, cold cargo build on 4 cores).
scripts/verify fast on whichever VM has a free slot (30–60 min with queue).
Notarize, staple, spctl -a, publish pre-release and update #146: only once a credential exists. After it does, this is one command plus Apple's service time.

Duplicate: #319 is the earlier copy of this job; I report on #321 only.

**Takeover (J124c, Sonnet 5.5)** — the previous Codex job stopped on a provider rate limit; I continue from its work, nothing is restarted. State found: - Branch `j124-signed-macos` exists only locally (never pushed), head `eb5939013`, base `7add12640` (origin/dev is now 29 commits ahead). One commit: `scripts/macos-release`. Its worktree is clean; no uncommitted work, nothing to rescue. - compute01 holds only a gate snapshot (`~/worktrees/j124-signed-macos`, branch `master`, commits `c63c758`/`cd42339`); its `verify-fast.log` there ends `VERIFY_EXIT=0` but for a snapshot, not this branch head, so I treat it as no evidence. dev-02 has an empty worktree at the base. - No J124 processes are left on either VM (the running jobs belong to j129, j130, m128 and others). Mac: `/tmp/mac-bench.lock` absent, nothing running. - Re-checked 1Password just now (metadata only, under the lock): the service account still sees one vault with three items (`Apple Certificates`, `Infraternal Release Token`, `Infraternal / Cloudflare Token`), active and archived. There is still no notarization credential. **Notarization stays blocked on the owner.** Plan (own branch `j124c-signed-macos` from `eb5939013`, then rebased on origin/dev): 1. Review fixes to the script (30 min): the env var is misspelled `INFRATERAL_NOTARY_PROFILE`; the lock is a `mkdir` directory, which does not exclude a `flock(2)` holder on the same path (macOS has no `flock` binary), so use BSD `lockf` on the file, which is flock(2)-compatible. 2. Add a `--skip-notarize` mode (smallest change that lets me prove the build and signing now): build, sign, `codesign --verify --strict` on the Mac. Output is named UNNOTARIZED and is not a release (45–90 min, cold cargo build on 4 cores). 3. `scripts/verify fast` on whichever VM has a free slot (30–60 min with queue). 4. Notarize, staple, `spctl -a`, publish pre-release and update #146: only once a credential exists. After it does, this is one command plus Apple's service time. Duplicate: #319 is the earlier copy of this job; I report on #321 only.

kayg referenced this issue

2026-11-03 10:09:29 +00:00

J124: ship signed and notarized arm64 macOS CLI and capture helper #319

kayg commented

2026-11-03 10:29:34 +00:00

Author

Owner

J124c progress and blockers — branch j124c-signed-macos (pushed), head 5ff05d5de, base origin/dev 7c082bddf. Commits on top of the previous job's acacdad52: 3ecb0a29b, b0168b3a1, 16490dc3b, 956226ff7, fb08ac57b, 5ff05d5de. (Correction to my takeover comment: dev-02's ~/worktrees/j124 is a checkout at the base with a leftover log, not an empty tree; no J124 process was running.)

What the Mac runs showed (all under the lock, secrets never in argv or logs)

The pinned identity was never a Developer ID. identity.sha1 in the dedicated keychain is the self-signed Infraternal Dev Signing certificate (reported CSSMERR_TP_NOT_TRUSTED without -v). The previous script correctly refused it. The Developer ID is the Developer ID Application.p12 attachment of 1Password item Apple Certificates; its password field is the p12 password.
Fix (16490dc3b): the script now picks the one valid Developer ID Application: identity by kind and imports the p12 from 1Password when it is missing. Both the p12 password and the keychain password go to security -i on stdin. Tested end to end: I deleted the identity and the script re-imported it by itself.
codesign --keychain said no identity found for a valid identity (dev and Developer ID alike, any hash case, by name, ssh and GUI session, either unlock method). Unified log: it gives up after two SecItemCopyMatching. With the keychain on the user search list both sign. Fix (fb08ac57b): prepend it for the run and restore the exact original list on exit. Checked after a failed run: list is login + System again, keychain relocked, scratch removed, lock released.
Lock (3ecb0a29b): macOS has no flock; the old mkdir lock would not exclude a flock(2) holder. Now lockf on /tmp/mac-bench.lock. Tested both directions against Python fcntl.flock.
.cargo/rustc.sh (D243 driver) needs bash 4.3 (local -n); macOS has 3.2. The script sets CARGO_BUILD_RUSTC and equivalent --remap-path-prefix flags (956226ff7). I did not touch the D243 driver.

Signing evidence (throwaway run of the script's own signing steps on the two artifacts that build on the Mac; output masked)

infraternal-desktop-helper: codesign --verify --strict --verbose=2  exit=0   (valid on disk; satisfies its Designated Requirement)
  Identifier=infraternal-desktop-helper  CodeDirectory v=20500 flags=0x10000(runtime)  Timestamp=3 Nov 2026 at 2:27:27 AM  Authority lines: 3
InfraternalCaptureHelper.app: codesign --verify --strict --verbose=2  exit=0 (valid on disk; satisfies its Designated Requirement)
  Identifier=com.infraternal.desktop.helper  CodeDirectory v=20500 flags=0x10000(runtime)  Timestamp=3 Nov 2026 at 2:27:27 AM  Authority lines: 3
spctl -a -vv InfraternalCaptureHelper.app: rejected   source=Unnotarized Developer ID

So signing with the owner's Developer ID works (hardened runtime, secure timestamp, full chain). spctl rejects only because the ticket is missing, which is the expected state before notarization. spctl -a does not pass yet and nothing is stapled.

Two blockers I cannot remove (D321 is not done)

A. No notarization credential (owner). The service account sees one vault with three items (Apple Certificates, Infraternal Release Token, Infraternal / Cloudflare Token); none holds an App Store Connect API key or an Apple ID app-specific password, and the keychain has no infraternal-notary profile. Needed from the owner: an API key (.p8, key ID, issuer ID) in a 1Password item in Apps / Infraternal — or run notarytool store-credentials themselves (command in the script header).

B. The infraternal CLI does not build on macOS. The first cargo build stops in infraternal-shim's build script (unsupported Zig build host). Two separate causes, neither mine to fix: scripts/auth-toolchain maps only Linux x86_64/aarch64 (macOS reports arm64, D213), and after that the shim itself uses Linux-only APIs (signalfd, peer credentials, SIGRTMAX, flistxattr, ioctl), which is #320. crates/infraternal depends on the shim unconditionally and calls it from main.rs, so remote,desktop on Darwin needs a portability slice first. #146 shows nobody has built the Mac CLI yet: J123 never produced one and earlier jobs hit the same Zig wall. This is days, not the 3 hours of this job, so per the scope leash I stopped instead of porting.

Decisions needed (my recommendation)

Credential for A: owner provides it (above).
For B, either (a) run #320 as the next slice, with a D213 extension for a macOS Zig host (a pinned archive and SHA-256 for the same Zig 0.15.2), or (b) ship a first pre-release with only the signed capture helper and Rust helper, so app-window capture can be tried against an existing Linux-hosted infraternal agent... which is not possible, because the helper needs the Mac agent to run. So I recommend (a).

Gate: scripts/verify fast is queued on dev-02 at head 5ff05d5de; output follows in the next comment. The change is one script, so the Rust rows should be unaffected.

**J124c progress and blockers** — branch `j124c-signed-macos` (pushed), head `5ff05d5de`, base origin/dev `7c082bddf`. Commits on top of the previous job's `acacdad52`: `3ecb0a29b`, `b0168b3a1`, `16490dc3b`, `956226ff7`, `fb08ac57b`, `5ff05d5de`. (Correction to my takeover comment: dev-02's `~/worktrees/j124` is a checkout at the base with a leftover log, not an empty tree; no J124 process was running.) ## What the Mac runs showed (all under the lock, secrets never in argv or logs) 1. **The pinned identity was never a Developer ID.** `identity.sha1` in the dedicated keychain is the self-signed `Infraternal Dev Signing` certificate (reported `CSSMERR_TP_NOT_TRUSTED` without `-v`). The previous script correctly refused it. The Developer ID is the `Developer ID Application.p12` attachment of 1Password item `Apple Certificates`; its `password` field is the p12 password. 2. **Fix (16490dc3b):** the script now picks the one valid `Developer ID Application:` identity by kind and imports the p12 from 1Password when it is missing. Both the p12 password and the keychain password go to `security -i` on stdin. Tested end to end: I deleted the identity and the script re-imported it by itself. 3. **`codesign --keychain` said `no identity found` for a valid identity** (dev and Developer ID alike, any hash case, by name, ssh and GUI session, either unlock method). Unified log: it gives up after two `SecItemCopyMatching`. With the keychain on the user search list both sign. Fix (fb08ac57b): prepend it for the run and restore the exact original list on exit. Checked after a failed run: list is `login` + `System` again, keychain relocked, scratch removed, lock released. 4. **Lock (3ecb0a29b):** macOS has no `flock`; the old `mkdir` lock would not exclude a `flock(2)` holder. Now `lockf` on `/tmp/mac-bench.lock`. Tested both directions against Python `fcntl.flock`. 5. **`.cargo/rustc.sh` (D243 driver) needs bash 4.3** (`local -n`); macOS has 3.2. The script sets `CARGO_BUILD_RUSTC` and equivalent `--remap-path-prefix` flags (956226ff7). I did not touch the D243 driver. ## Signing evidence (throwaway run of the script's own signing steps on the two artifacts that build on the Mac; output masked) ``` infraternal-desktop-helper: codesign --verify --strict --verbose=2 exit=0 (valid on disk; satisfies its Designated Requirement) Identifier=infraternal-desktop-helper CodeDirectory v=20500 flags=0x10000(runtime) Timestamp=3 Nov 2026 at 2:27:27 AM Authority lines: 3 InfraternalCaptureHelper.app: codesign --verify --strict --verbose=2 exit=0 (valid on disk; satisfies its Designated Requirement) Identifier=com.infraternal.desktop.helper CodeDirectory v=20500 flags=0x10000(runtime) Timestamp=3 Nov 2026 at 2:27:27 AM Authority lines: 3 spctl -a -vv InfraternalCaptureHelper.app: rejected source=Unnotarized Developer ID ``` So signing with the owner's Developer ID works (hardened runtime, secure timestamp, full chain). `spctl` rejects only because the ticket is missing, which is the expected state before notarization. **`spctl -a` does not pass yet and nothing is stapled.** ## Two blockers I cannot remove (D321 is not done) **A. No notarization credential (owner).** The service account sees one vault with three items (`Apple Certificates`, `Infraternal Release Token`, `Infraternal / Cloudflare Token`); none holds an App Store Connect API key or an Apple ID app-specific password, and the keychain has no `infraternal-notary` profile. Needed from the owner: an API key (`.p8`, key ID, issuer ID) in a 1Password item in `Apps / Infraternal` — or run `notarytool store-credentials` themselves (command in the script header). **B. The `infraternal` CLI does not build on macOS.** The first cargo build stops in `infraternal-shim`'s build script (`unsupported Zig build host`). Two separate causes, neither mine to fix: `scripts/auth-toolchain` maps only Linux x86_64/aarch64 (macOS reports `arm64`, D213), and after that the shim itself uses Linux-only APIs (`signalfd`, peer credentials, `SIGRTMAX`, `flistxattr`, `ioctl`), which is #320. `crates/infraternal` depends on the shim unconditionally and calls it from `main.rs`, so `remote,desktop` on Darwin needs a portability slice first. #146 shows nobody has built the Mac CLI yet: J123 never produced one and earlier jobs hit the same Zig wall. This is days, not the 3 hours of this job, so per the scope leash I stopped instead of porting. ## Decisions needed (my recommendation) 1. Credential for A: owner provides it (above). 2. For B, either (a) run #320 as the next slice, with a D213 extension for a macOS Zig host (a pinned archive and SHA-256 for the same Zig 0.15.2), or (b) ship a first pre-release with only the signed capture helper and Rust helper, so app-window capture can be tried against an existing Linux-hosted infraternal agent... which is not possible, because the helper needs the Mac agent to run. So I recommend (a). Gate: `scripts/verify fast` is queued on dev-02 at head `5ff05d5de`; output follows in the next comment. The change is one script, so the Rust rows should be unaffected.

kayg commented

2026-11-03 12:22:49 +00:00

Author

Owner

J124c finish — NOT DONE: D321 is blocked on two things only the owner/orchestrator can resolve (details in my previous comment).

Branch j124c-signed-macos (pushed), head 5ff05d5de4b4a13b374fa953805ecd59d169415f, base origin/dev 7c082bddf. The only changed file is scripts/macos-release; no Rust, UI or protocol code changed.

Gate: `scripts/verify fast` on dev-02 at the head above (verbatim summary)

+---------------------------+--------------+
| Rust gate                 | Result       |
+---------------------------+--------------+
| fmt                       | PASS         |
| VT native fmt             | PASS         |
| CLI plugin compile-out    | PASS         |
| clippy                    | PASS         |
| SSH runtime test helper   | PASS         |
| real-binary fixture paths | PASS         |
| test                      | PASS         |
| SSH inode reuse fixture   | PASS         |
| shim process-per-user     | FAIL (101)   |
| cargo-deny                | PASS         |
| gate architecture         | PASS         |
| static builds             | PASS         |
+---------------------------+--------------+
VERIFY_EXIT=1

The failing row is infraternal-shim --lib: session::resize_checks::native_resize_refusal_preserves_peer_and_pty panicked (session recovery probe failed: exact), 210 passed / 1 failed, in 86.9 s on a heavily loaded VM. I could not reproduce it: the test alone passes 3/3 on unmodified base 7c082bddf and 3/3 on my head; the full row command passes 211/211 on base (44.1 s) and 211/211 on my head (44.3 s). So I cannot prove it fails on base; it is a load-dependent failure in a Linux-only area my change does not touch (see also #315, #324). I did not rerun the full gate.

Done

Signing works with the owner's Developer ID from 1Password (import via security -i on stdin, hardened runtime, secure timestamp): codesign --verify --strict exit 0 for InfraternalCaptureHelper.app and infraternal-desktop-helper (evidence in the previous comment).
Script fixes: Developer ID chosen by kind and imported on first run; keychain on the search list for the run and restored on exit (also on failure); lockf lock compatible with flock(2) (J80's job on the Mac uses a perl flock on the same file, so the two exclude each other); rustc override for bash 3.2; --skip-notarize mode; header lists prerequisites.

Not done

spctl -a does not pass and nothing is stapled: there is no notarization credential (blocker A).
No release asset, no checksums, no #146 owner-steps update, no #265 note: the infraternal CLI cannot be built on macOS (blocker B: Zig host in scripts/auth-toolchain, D213; Linux-only shim, #320).

Decisions needed (recommendation)

Owner: provide an App Store Connect API key (.p8, key ID, issuer ID) in Apps / Infraternal, or run the notarytool store-credentials command from the script header.
Orchestrator/owner: schedule #320 plus a D213 extension (pinned macOS Zig archive and SHA-256, same 0.15.2) before J124 can be finished. Correcting my earlier wording: a helper-only release is useless without the Mac agent, so there is no useful partial release. After 1 and 2, finishing is scripts/macos-release <dir> on the Mac plus Apple's notarization time.

State left behind

Mac: my clone, target and output removed; the imported Developer ID removed from the dedicated keychain (the script re-imports on demand); keychain locked; user search list is login + System as found; /tmp/mac-bench.lock is held by J80, not me; lume's login keychain and TCC were never touched. One thing to know: a spctl line printed the certificate's holder name during my testing; I kept it out of the repo and this issue. dev-02: my worktrees and the previous job's 42 GB target removed; logs remain under ~/.cache/codex-scratch/j124c/. compute01: the previous job's gate snapshot in ~/worktrees/j124-signed-macos and ~/.cache/codex-scratch/J124 is still there and is not mine to delete.

**J124c finish — NOT DONE: D321 is blocked on two things only the owner/orchestrator can resolve** (details in my previous comment). Branch `j124c-signed-macos` (pushed), **head `5ff05d5de4b4a13b374fa953805ecd59d169415f`**, base origin/dev `7c082bddf`. The only changed file is `scripts/macos-release`; no Rust, UI or protocol code changed. ## Gate: `scripts/verify fast` on dev-02 at the head above (verbatim summary) ``` +---------------------------+--------------+ | Rust gate | Result | +---------------------------+--------------+ | fmt | PASS | | VT native fmt | PASS | | CLI plugin compile-out | PASS | | clippy | PASS | | SSH runtime test helper | PASS | | real-binary fixture paths | PASS | | test | PASS | | SSH inode reuse fixture | PASS | | shim process-per-user | FAIL (101) | | cargo-deny | PASS | | gate architecture | PASS | | static builds | PASS | +---------------------------+--------------+ VERIFY_EXIT=1 ``` The failing row is `infraternal-shim --lib`: `session::resize_checks::native_resize_refusal_preserves_peer_and_pty` panicked (`session recovery probe failed: exact`), 210 passed / 1 failed, in 86.9 s on a heavily loaded VM. I could not reproduce it: the test alone passes 3/3 on unmodified base `7c082bddf` and 3/3 on my head; the **full row command** passes 211/211 on base (44.1 s) and 211/211 on my head (44.3 s). So I cannot prove it fails on base; it is a load-dependent failure in a Linux-only area my change does not touch (see also #315, #324). I did not rerun the full gate. ## Done - Signing works with the owner's Developer ID from 1Password (import via `security -i` on stdin, hardened runtime, secure timestamp): `codesign --verify --strict` exit 0 for `InfraternalCaptureHelper.app` and `infraternal-desktop-helper` (evidence in the previous comment). - Script fixes: Developer ID chosen by kind and imported on first run; keychain on the search list for the run and restored on exit (also on failure); `lockf` lock compatible with `flock(2)` (J80's job on the Mac uses a perl `flock` on the same file, so the two exclude each other); rustc override for bash 3.2; `--skip-notarize` mode; header lists prerequisites. ## Not done - `spctl -a` does **not** pass and nothing is stapled: there is no notarization credential (blocker A). - No release asset, no checksums, no #146 owner-steps update, no #265 note: the `infraternal` CLI cannot be built on macOS (blocker B: Zig host in `scripts/auth-toolchain`, D213; Linux-only shim, #320). ## Decisions needed (recommendation) 1. Owner: provide an App Store Connect API key (.p8, key ID, issuer ID) in `Apps / Infraternal`, or run the `notarytool store-credentials` command from the script header. 2. Orchestrator/owner: schedule #320 plus a D213 extension (pinned macOS Zig archive and SHA-256, same 0.15.2) before J124 can be finished. Correcting my earlier wording: a helper-only release is useless without the Mac agent, so there is no useful partial release. After 1 and 2, finishing is `scripts/macos-release <dir>` on the Mac plus Apple's notarization time. ## State left behind Mac: my clone, target and output removed; the imported Developer ID removed from the dedicated keychain (the script re-imports on demand); keychain locked; user search list is login + System as found; `/tmp/mac-bench.lock` is held by J80, not me; `lume`'s login keychain and TCC were never touched. One thing to know: a `spctl` line printed the certificate's holder name during my testing; I kept it out of the repo and this issue. dev-02: my worktrees and the previous job's 42 GB target removed; logs remain under `~/.cache/codex-scratch/j124c/`. compute01: the previous job's gate snapshot in `~/worktrees/j124-signed-macos` and `~/.cache/codex-scratch/J124` is still there and is not mine to delete.

kayg referenced this issue

2026-11-05 18:10:54 +00:00

Housekeeping 2026-11-05 #369

kayg referenced this issue

2026-11-10 05:22:52 +00:00

J470: add a Mac node from a production build (release darwin binary, infraternal up on macOS) #483

Rows
Columns

J124: signed and notarized arm64 macOS CLI and capture helper #321

Goal

Plan and estimate (3 hours)

Constraints

What the Mac runs showed (all under the lock, secrets never in argv or logs)

Signing evidence (throwaway run of the script's own signing steps on the two artifacts that build on the Mac; output masked)

Two blockers I cannot remove (D321 is not done)

Decisions needed (my recommendation)

Gate: scripts/verify fast on dev-02 at the head above (verbatim summary)

Done

Not done

Decisions needed (recommendation)

State left behind

Gate: `scripts/verify fast` on dev-02 at the head above (verbatim summary)