Ota Authority Launcher

Trusted launcher for Ota crossing authority. It gives Ota a protected, challenge-bound session for independently authorized work without exposing broker credentials, signing material, or reusable authority to repository tasks.

Important

This repository contains the implemented, pressure-proven Linux/systemd carrier for Ota's bounded audited-crossing authority path. It is currently source-distributed: operators must pin one reviewed immutable revision and provision it outside repository-controlled execution. The project does not operate a hosted authority service, bundle reusable authority, or publish a standalone stable release artifact yet.

Current implementation boundary

The portable Unix carrier is a session-isolating exec wrapper. It:

• loads launcher configuration only from /etc/ota/authority-launcher.json;
• reconciles the selected authority label with Ota's fixed /etc/ota/crossing-brokers.json binding;
• accepts one already-connected administrator-supplied Unix stream;
• starts one fixed, protected Ota binary as a configured non-root principal;
• gives Ota only its configured session descriptor and marks every other open descriptor close-on-exec; and
• proxies the framed Core protocol without interpreting or rewriting signed messages.

The repository now also contains the feature-gated ota-authority-attestor foundation. That separate Linux service owns one systemd-delivered Ed25519 credential, accepts one protected SOCK_SEQPACKET signing request, verifies the live launcher peer, derives producer-owned freshness, durably records the exact canonical response bytes, and returns the identical response for an identical unexpired replay. The launcher-side verifier loads only the protected public producer binding and independently checks the response projection, identity, signature, audience, key validity, and freshness.

The protected systemd launcher collects the complete ordered ota.authority-launcher.systemd/v4 and ota.authority-job-principal.systemd/v2 observation sets and invokes that producer. It verifies protected installation identities, exact systemd runtime properties, process containment, account/sudo/Polkit posture, protected-path and host-socket access, and Ota process-access denial before relaying the independently verified signed V3 attestation to Core. Any missing or mismatched observation refuses. This establishes a real local V3 attestation bridge. It additionally forwards Core's exact authorization request to one protected, installation-bound local broker proxy, relays only signed authorization decisions, then relays one exact prepared lease and consumption response. Core keeps the systemd transaction private and in memory while the launcher journals the full relay and acknowledges that journal back to Core. After one consumed lease, the launcher retains the exact child, transient scope, and active-slot journal while selected work runs. Core sends one terminal transaction-bound completion over the private session; the launcher persists it before acknowledgement, reconciles the observed child exit, removes the exact scope and empty cgroup, reaps the child, removes the slot, and only then emits terminal finalization evidence.

With protected-attestor enabled, the same protected socket also accepts the closed Protocol capability-observation probe. It binds Core's fresh challenge to one exact launcher invocation, prepares the stopped Ota child and transient scope, derives the protected capability from retained live observations, delegates only projection signing to the Attestor, cleans up the child and scope, and returns only the signed public projection. This route does not authorize execution or contact OIDC or another provider.

The V4 service retains ProtectProc=invisible and ProcSubset=pid. On systemd 253 or newer, the manager opens /proc/sys/kernel/random/boot_id read-only through OpenFile= and passes it as ota-boot-id; the socket unit names its listener ota-launcher-listener. Launcher requires exactly those two named descriptors for its current process, accepts either descriptor ordering, and reobserves the boot descriptor as read-only procfs before capability reconciliation. The selected child's complete stopped descriptor table is independently restricted to its six declared roles, so the boot descriptor is not inherited. No other service unit receives a wider procfs view.

The pressure provisioner installs fixed root-owned 0400 empty verifier and binding snapshots beneath /etc/ota/secret-delivery. Launcher opens and retains them before selected-child creation, then revalidates their exact descriptors and signed bytes before private V1 snapshot disclosure. A separate root-owned replay directory at /var/lib/ota/authority-launcher/authority-snapshot-replay reserves before disclosure and is consumed only after exact V2 or additive V3 binding reconciliation for V1 snapshots. The additive raw-store V2 snapshot reserves the same way but is consumed only after exact V4 reconciliation. Launcher structurally and cryptographically verifies the retained raw signed stores, then privately relays them in the V2 snapshot. Core semantically verifies the complete bounded transport-dependency graph and record against its embedded expectation; only the subsequent V4 binding exchange carries the record identity. V1/V2/V3 substitutes for that V2/V4 route refuse. Ordinary non-secret completion does not require these stores. The empty structural snapshots grant no verifier or provider authority and prove no provider contact, materialization, or secret delivery.

The feature-gated ota-authority-pressure-peer binary is an exception for conformance testing only. It uses fixed public test keys and deterministic scenarios to exercise protocol v2 through a real launcher/Core process chain. The hosted lane runs Core as a dedicated non-root principal with no supplemental groups, no readable Docker socket, root-only pressure-peer access, protected authority files, and a strict signed protected-launcher profile. Its scenarios prove live consumption plus expired, revoked, wrong-scope, already-consumed, unavailable, timed-out, cancelled, and ambiguous pre-execution refusal. A paired recovery scenario withholds an already-consumed response, then proves that a fresh launcher session re-queries the exact durable intent, closes the abandoned transaction without execution, and requires a newly consumed lease before work starts. The separate reference-store regression proves atomic one-use state. The pressure peer is not installed by default and must never be used as an operator broker or authority issuer.

Immediately before signing each challenge, the pressure attestor reconciles the live Ota child through Linux procfs: all UID/GID slots, supplementary groups, capabilities, no_new_privs, the exact launcher environment, the unnamed close-on-exec Unix session, protected-path access, common host-control sockets, and measured launcher/configuration identities.

This is bounded conformance evidence for the test launcher boundary. It is not provider attestation, does not establish host-wide isolation, and does not turn the production launcher into an issuer.

Why it exists

Some repository operations need more than ordinary task admission. Production deployment, database migration, package publication, infrastructure mutation, signing, and secret rotation may require an independently issued authorization that is valid for exactly one verified invocation.

Ota Core derives the exact contract and execution scope, verifies authority, executes the selected work, and archives bounded evidence. The authority launcher owns the privileged boundary that Core must not carry in a normal repository process:

• protected broker transport or workload credentials;
• challenge-bound runtime-attestation collection and its protected producer boundary;
• delivery of one non-inheritable launcher session to Ota; and
• isolation of authority material from selected task processes.

Execution model

sequenceDiagram
    autonumber
    participant Operator as Protected workflow or operator
    participant Repo as Repository contract
    participant Launcher as authority-launcher
    participant Attestor as Protected attestor
    participant Ota as Ota Core
    participant Broker as Protected authority session
    participant Task as Selected task

    Operator->>Launcher: Select non-secret authority label and Ota command
    Launcher->>Launcher: Verify fixed config, binary, principal, and Unix session
    Launcher->>Ota: Start fixed binary with one inherited session FD
    Repo->>Ota: Select authority_id and governed lane
    Ota->>Ota: Freeze contract, scope, work unit, and nonce
    Ota->>Launcher: Send challenge over protected session
    Launcher->>Launcher: Collect complete closed-profile evidence
    Launcher->>Attestor: Send identity-bound signing request
    Attestor->>Attestor: Verify peer, sign once, and persist exact response
    Attestor-->>Launcher: Return signed challenge-bound attestation
    Launcher->>Launcher: Verify response and claims projection
    Launcher-->>Ota: Relay only the signed attestation
    Ota->>Launcher: Request exact-scope authorization
    Launcher->>Broker: Proxy signed request
    Broker-->>Launcher: Return signed decision and prepared lease
    Launcher-->>Ota: Return signed broker evidence
    Ota->>Ota: Create durable pending crossing transaction
    Ota->>Launcher: Consume lease for exact transaction
    Launcher->>Broker: Atomically consume lease once
    Broker-->>Launcher: Return signed consumption result
    Launcher-->>Ota: Return transaction-bound result

    alt Verification, authorization, or consumption fails
        Ota-->>Repo: Refuse before execution starts
    else Lease is verified as consumed
        Ota->>Task: Execute exact selected work
        Task-->>Ota: Return terminal outcome
        Ota->>Ota: Finalize receipt and archive evidence
    end

Loading

The launcher does not decide what a repository task means. Ota Core remains the canonical owner of semantic scope, admission rules, refusal behavior, receipts, and archive verification. Core derives and verifies the shared Protocol identities; the launcher cannot rewrite them.

Build and invoke

The repository currently supports Rust 1.95.0. The production systemd carrier is Linux-only; the portable Unix wrapper and non-Linux refusal paths remain build-tested on macOS. Use the locked, all-feature verification surface before changing the carrier:

cargo build --locked --release --all-features
cargo test --locked --all-targets --all-features
cargo clippy --locked --all-targets --all-features -- -D warnings

The launcher deliberately has no repository-controlled config flag. Its protected configuration has this initial shape:

{
  "schema_version": 1,
  "ota_binary": "/usr/local/bin/ota",
  "run_as": { "uid": 1001, "gid": 1001 },
  "environment": {
    "HOME": "/home/ota-runner",
    "LANG": "C.UTF-8",
    "LOGNAME": "ota-runner",
    "PATH": "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
    "USER": "ota-runner"
  },
  "sessions": [
    {
      "authority_id": "platform-release-authority",
      "broker_session_descriptor": 4,
      "expected_peer": { "uid": 0, "gid": 0 }
    }
  ]
}

The administrator-controlled parent starts the launcher as root and opens the authenticated Unix stream at descriptor 4, then executes:

ota-authority-launcher run \
  --authority-id platform-release-authority \
  -- run publish

Only ota run, ota up, ota proof runtime, and ota proof lifecycle are accepted. The Ota binary path, execution principal, complete child environment, source session descriptor, and Ota-facing descriptor come from protected system configuration, never repository files or inherited environment variables. The complete Core broker binding format is defined in the Broker Crossing Authority reference.

Trust boundary

The launcher is administrator-operated infrastructure outside the repository and job-controlled filesystem. Repository files, workflow YAML, environment variables, policy packs, and task input must not select or replace its trust roots, broker credentials, verifier keys, or protected transport.

Selected task processes must not inherit or reacquire the launcher session. The launcher fails closed when it cannot establish its local process, descriptor, configuration, or session boundary. Ota Core verifies signed attestation, freshness, semantic scope, and one-use authorization state.

The target repository declares only an authority identity:

governance:
  crossing_authority:
    authority_id: platform-release-authority

Administrator-owned protected configuration binds that identity to the launcher and broker. No usable key, grant, lease, credential, or trust path belongs in ota.yaml.

Systemd service foundation

The Linux systemd_protected_launcher/v1 service path accepts only the fixed socket-activated listener, derives the job peer through SO_PEERCRED, opens the allowed repository through the configured execution principal, and prepares the exact protected Ota binary as a stopped root child. Before fork it creates and fsyncs a root-owned active-slot intent under /var/lib/ota/authority-launcher/active; after fork it atomically binds the request, working-directory device/inode, principal mapping, PID/start time, binary identity, and complete child descriptor boundary.

The Linux pressure unit needs root system-manager access, bounded CAP_SYS_PTRACE so it can re-observe protected process and stopped-child descriptor posture, and bounded CAP_DAC_OVERRIDE so it can traverse the execution principal's exact private 0700 receipt hierarchy and publish the producer-signed archive sidecar. CAP_DAC_OVERRIDE is present only in the unit's exact capability bounding set, not its ambient set; the mount namespace, protected signing-key paths, explicit writable roots, owner/mode checks, and signed archive identity remain mandatory. It binds listening sockets through protected file metadata, descriptor type, socket options, and exact systemd unit relationships rather than treating /proc/net/unix path spelling as authority. These are bounded adapter requirements, not evidence of provider-attested isolation; the effective unit, capability, mount, process, and socket posture remain part of the signed hardening profile.

The child receives only standard streams, the systemd profile's fixed private Ota session descriptor, the fixed binary descriptor, and the retained repository descriptor. Production code re-observes that exact root/stopped posture and descriptor set before recording the child. It then asks the root systemd manager for one request-derived transient scope in the fixed invocation slice, confirms the exact unit properties and sole PID through the kernel cgroup, and durably records that scope. Only after that persistence does the launcher resume the exact PID through pidfd, admit one bounded ota_process_posture/v1 frame, and reconcile its identity, PID/start time, Ota binary, and principal mapping to the prepared child. It then sends one identity-bound local continuation that binds the exact invocation, child, working directory, posture, and principal mapping so Core can parse the command and freeze the real semantic scope. The launcher submits Core's exact challenge plus its complete observed profile to the separately credentialed protected attestor, independently verifies the returned signature and claims projection, then relays only that signed V3 response. It reconciles Core's exact matching authorization request, connects only to the protected broker proxy bound by the installation manifest, consumes one private preface carrying kernel-supplied SCM_CREDENTIALS and SCM_PIDFD for the accepting service, and retains that exact process identity across relay traffic. This distinction is required because PID 1 owns a systemd-activated listener; SO_PEERCRED alone does not identify the service process that accepted the connection. The launcher then relays signed decisions, the exact prepared lease, and one consumption response back to Core. Core returns an identity-bound decision acknowledgement and an identity-bound consumption admission after verifying the launcher's durable relay evidence. The launcher-owned active-slot journal is the durable authority record; Core's systemd transaction remains private in-memory state. After consumption, Core may execute the exact selected lane and must return one completion binding the pending and terminal transaction identities. The launcher persists that completion before acknowledgement, reconciles the actual child exit, stops the complete scope, confirms it absent and its cgroup empty or absent, reaps the child, removes the slot, and only then emits terminal finalization.

On startup, retained journals are reconciled before accepting a client. A valid child- or scope-bearing temporary journal is promoted rather than discarded. Intent-only state remains a hard refusal because it cannot establish child absence. An exact pre-scope child is terminated through Linux pidfd; a scope-bearing journal additionally requires the exact unit and kernel cgroup to be stopped and observed empty. PID reuse, identity mismatch, unsupported cleanup, or any uncertain outcome retains the slot and fails closed.

The non-default secret-delivery-pressure feature contains the first protected capability foundation for V12.1 Step 7. It opens only the fixed verifier and binding stores beneath retained directory descriptors with Linux openat2 no-symlink, no-magic-link, no-mount-crossing, and beneath-only resolution; requires the authority directory to be private and both stores to be root-owned regular mode-0400 files; retains exact bytes and descriptor identities; and can observe a retained live Unix-stream session descriptor and invocation cgroup before deriving a protocol-verified ProtectedLauncherCapabilityV1. After signed admission and lease consumption, the selected child may either use the immutable V1 binding exchange, request one private V1 protected-authority snapshot followed by one snapshot-bound V2 or additive V3 binding over that same inherited session, or request one canonical raw-store V2 snapshot followed only by V4. V3 carries one opaque Core-derived transport-dependency record identity. The V2 snapshot privately relays the descriptor-bound raw verifier and binding stores, including the administrator-signed bundle that retains the complete bounded transport-dependency graph and record expectation. Launcher structurally and cryptographically verifies those retained stores before relay; Core semantically verifies the complete graph and record against its embedded expectation. Only the subsequent V4 binding exchange carries and binds the record identity. Launcher does not interpret the graph or prepare transport. V1/V2/V3 substitutes for the V2/V4 route refuse. Launcher derives the capability from the exact retained child, scope, cgroup, session, stores, authority context, installation evidence, and replay state, then returns one Protocol-reconciled private binding plus its signed public projection. The private capability identity never enters the public projection. Duplicate, interleaved, reversed, or replayed exchange messages refuse. Non-secret execution still proceeds directly to its completion frame. This route does not request an OIDC token, contact Google, materialize or inject a secret, publish positive delivery evidence, or activate Step 8.

The same protected observation route loads one administrator-installed ProtectedLauncherAuthorityContextV1 whose file identity is a singular protected-installation role. It reconciles the exact installed Launcher and Ota artifacts, source-bound build identities, Protocol revision, compatibility range, launcher profile, and Linux/x86_64 target before capability use. The root Launcher generates the invocation nonce itself and observes the canonical boot UUID through the retained manager-opened V4 descriptor, rechecking its procfs, access-mode, metadata, content, and identity immediately before capability reconciliation. Repository, workflow, environment, and request values cannot provide those identities. This is context and observation ownership only, not provider evidence.

This path permits selected execution only after signed V3 admission and one bounded consumed lease. The selected Ota command creates its ordinary transaction-bound crossing receipt/archive; launcher terminal evidence separately binds Core's completion to exact child, scope, cgroup, and slot cleanup. A live launcher records the exit code it observed while reaping the child. After a launcher restart, finalization instead records recovered_absent_completion_bound, binds verified child absence to Core's durable completion, and explicitly makes no observed-exit or child-reaped claim. The implementation persists a protected finalization journal before deleting the active slot, asks the producer to sign the cleanup record and a separate exact archive attachment, reopens the private archive through the execution-principal repository descriptor, and verifies its owner, content identity, and transaction before atomically publishing a root-owned sidecar. Both .ota, .ota/receipts, and .ota/contracts must be owned by the execution principal with mode 0700; the job principal never reads the private receipt or contract-snapshot directories and only acknowledges the exact signed result. The protected journal then retains the exact terminal frame until the client acknowledges that terminal identity. Reconnect recovery starts from retained launcher state rather than scanning repository files.

Production client and protected history

ota-authority-systemd-client is the production invocation client for the fixed /run/ota/authority-launcher.sock boundary. It accepts only run, up, proof runtime, and proof lifecycle, preserves one globally ordered stdout/stderr stream, verifies the exact terminal record, and uses identity-bound finalization recovery after a disconnect. It has no pressure expectations, fault controls, alternate socket, or authority-material input:

ota-authority-systemd-client --authority-id release --repository . -- \
  run publish --grant release

Administrator-owned reboot pressure uses the separate feature-gated ota-authority-systemd-recovery-controller. The repository runner must be disabled and stopped; the controller arms one fixed completion, finalization-intent, or terminal-recorded fault and persists only the exact recovery request needed across reboot. A separate no-checkout trigger workflow invokes the installed production client from the exact bound runner cgroup; the root controller never impersonates that runner posture. The feature-gated trigger disables immediate client reconnect so the administrator-owned reboot remains the only recovery transition. The trigger's bounded disconnect is not evidence of the fault by itself; the root controller must verify the exact retained checkpoint. The administrator stops the runner before reboot, then performs a recovery-only exchange and publishes bounded public evidence. The final consumer workflow can verify and upload that evidence but cannot arm faults, control services, reboot the host, or read authority state. Recovered terminal evidence is fsynced before acknowledgement, so a controller crash cannot erase the Launcher recovery journal without leaving an exact durable observation. See docs/independently-administered-pressure.md.

The Launcher-side protected-history service uses the separate fixed /run/ota/authority-history.sock service and root-owned /etc/ota/authority-history.json binding. The binding is reconciled with the protected installation manifest through a cycle-free history-installation projection. That projection excludes only the binding file entry; the full manifest still binds and verifies the exact binding bytes. The binding fixes the admitted client executable, operator UID/GID and profile, service/socket identities, response ceilings, the canonical /var/lib/ota/authority-launcher/history/{blobs,catalog} roots, and exact repository-instance mapping. Alternate storage roots refuse even when they are otherwise administrator-owned and protected. The history peer must be non-root, hold no effective, permitted, inheritable, or ambient capabilities, use NoNewPrivileges=1, remain limited to its primary group and pidfd-live, and run the exact installed client. The kernel capability bounding set remains outside this operator-profile claim. Each response manifest binds the verified peer instance and non_agent attribution; the durable catalog binds the administrator- owned operator profile. The service repeats the complete pidfd, credentials, groups, capabilities, NoNewPrivileges, installed-executable, process-start, working-directory, and peer-identity reconciliation before its first response and immediately before terminal completion.

Before a successful finalization journal can advance, Launcher freezes and publishes three independent root-owned mode-0600 content-addressed objects: the receipt archive, the immutable contract snapshot named by that archive, and the producer-signed sidecar. Publication is descriptor-relative, no-follow, fsynced, create-new, and idempotent. The history reader prefers openat2; when its hardened service environment returns ENOSYS, it permits only an exact-basename openat(O_NOFOLLOW | O_CLOEXEC) fallback and still requires a root-owned mode-0600 regular file with one link, bounded size, and matching digest. Object identities derive first from manifest identity, entry ordinal, catalog identity, kind, content identity, length, and chunk count; the entry then binds all three object identities. Protected history never reopens a repository snapshot during operator reads and never returns a protected filesystem path or general read primitive.

Launcher verifies protected storage and producer signatures only. Core remains the sole semantic receipt/archive verifier. Immutable Linux/x64 PID 1 run 31823037642 proves the installed production client and protected-history source against Protocol 04a199a1eddd72b5b61958e0fe7f2d4e662e05cf, clean source-built Core d9d424168b1c1dad48351651c610789e54f74dcf, and Launcher c80828aa7b64a4bb8c1d9957d937d4fae4d70828. The retained artifacts report one valid and zero invalid protected archive, one catalog entry, three content-addressed objects, exact cleanup, and unchanged refusal worktrees without private signing material. The workflow controller provisioned the authority stack, so that run did not prove independently administered launcher separation or provider attestation. The separate runs below close the hardened-launcher branch.

The independently administered pressure lane separates those owners. An administrator prepares the host and registers a protected self-hosted runner; the repository workflow then invokes only the fixed production client and protected-history source. The runner itself must be the exact systemd service admitted by the closed profile; a sibling GitHub runner service cannot inherit that authority. Provisioning also refuses before its first authority write unless that runner is stopped, both selected principals are process-free, every managed authority service/socket is inactive, and the managed authority namespace is fresh. Activation starts freshly loaded socket units and verifies their exact protected group boundary and sole systemd ownership before public evidence is published; any loaded legacy or competing unit for a fixed socket path refuses. The runner's exact systemd unit remains gated on final protected installation-evidence publication throughout provisioning. See Independently Administered Systemd Pressure. Immutable Linux/x64 PID 1 run 31939777636 proves that consumer-only positive path against Protocol 04a199a1eddd72b5b61958e0fe7f2d4e662e05cf, clean source-built Core 634a2c169e083da4e02abd72a7bf29ae388ddf3d, and Launcher ea7480e8d8b8aa214c5602628fb6dfa6382e2088. It completed one consumed work unit with exact child/scope/cgroup/slot cleanup and one valid protected archive with zero invalid archives. This closes the positive hardened-launcher separation branch. The separate administrator-driven reboot/fault-recovery matrix is green in immutable Linux/x64 PID 1 run 31953535665 against Protocol 04a199a1eddd72b5b61958e0fe7f2d4e662e05cf, clean source-built Core e49f21ee77e522a614a776bcf17c9f9be16c8a90, and Launcher a348a13fd60b067266013cf8a0f047bbe274fd81. Its consumer artifact independently re-verifies the execution-completion, finalization-intent, and terminal-recorded reboot cases as three valid protected archives with zero invalid or legacy-unverified archives, unchanged repository state, and zero residual child, scope, cgroup, active-slot, or finalization state. Provider attestation remains optional stronger hardening and is not implied by this carrier.

Immutable Linux/x64 PID 1 run 34241049867, job 102111003771, proves the fixed capability-observation replay path is reconciled across the fresh managed-state inventory and effective Launcher ReadWritePaths at exact Launcher 8ca4763c1e5c6ef5ac06c2be5b778c49344c5030, Protocol e0af492ba8a6fbe01e805c79762909c9cda28198, and Core f921209561b26f38cdb74c5f20f71e0b6734ae0d. The same bounded invocation completed with exact child, scope, cgroup, and active-slot cleanup and one valid protected receipt archive with zero invalid archives. The retained artifact does not prove production capability-observation routing, accepted-session provenance, provider contact, OIDC exchange, secret materialization or delivery, Step 8, V12.2, or general governance.

Immutable Linux/x64 PID 1 run 31758094819 proves this pressure-only attachment and recovery path against Protocol 3e912f721ba9673090d14bcf5f88a2ee27a6b58a, Core cf3114f3d96d5c030c748a12b2e359586f0ded8c, and Launcher 6954a39aefd35b8df648534a6028c0206c0372f9. It does not turn the pressure client into a production operator surface. Only ota-authority-attestor receives the systemd-delivered signing credential; the launcher retains public verification truth only. Missing, malformed, oversized, self-inconsistent, or substituted posture, continuation, challenge, attestation, or authorization decision/admission fails closed and enters the same exact cleanup path. The decision and selected-execution paths have passed immutable Linux/x64 PID 1 systemd pressure in run 31664495937, including completed, failed, interrupted, replay-refused, and crash-recovered execution. The run does not establish provider-attested separation and predates the later portable launcher-finalization attachment proof.

The follow-on portable-finalization run 31758094819 proves that portable path across positive execution and completion-, finalization-, and terminal- crash recovery. All 21 terminal boundaries end with zero active slots, finalization journals, and scopes. Positive execution and those three terminal crash-recovery points each have one valid archive and zero invalid archives. A restart after durable Core completion uses finalization schema v2 to prove child absence without claiming that the restarted launcher observed the exit or reaped the child. Durable producer state retains distinct root-owned mode-0600 cleanup-finalization and archive-attachment issuance records. Independently administered launcher separation remained open in that run; later runs 31939777636 and 31953535665 close the hardened-launcher branch. Provider attestation remains optional stronger hardening. That run predates the production client and protected-history proof in run 31823037642 above.

The feature-gated ota-authority-systemd-pressure-client is the unprivileged side of that positive kernel proof. It connects only to /run/ota/authority-launcher.sock, submits one bounded LauncherInvocationRequestV1, streams bounded sequenced output, and accepts only a validated terminal frame with its caller-selected exact expected stage. Selected-success and selected-failure controls require identity-bound terminal cleanup evidence. Decision-only compatibility controls can instead require authorization_decision_verified_before_lease_boundary_removed; negative cases can instead require exact denied-decision or pre-authorization-protocol refusal; a posture-only, repository-open, or generic boundary failure cannot satisfy it. Before sending the request it requires the fixed socket and parent to have the protected root-owned posture and requires the connected Unix peer to be root-owned. It cannot select another socket, install configuration, mutate systemd, or provide authority. The binary is not installed as part of the production launcher.

Immutable crash/recovery pressure may additionally build the launcher with the systemd-pressure-faults feature. In that build only, a root-owned mode-0600 one-shot marker at /run/ota/authority-launcher-pressure-exit-after-scope terminates the service immediately after the exact child and scope have been durably journaled. The marker is removed and its parent is synced before termination. The repository job cannot create the marker; an administrator prepares it before dispatch. The next socket activation must reconcile and remove that exact boundary before it can accept another request. Production builds omit the feature and marker behavior.

Hosted normal pressure 31389237232 and root-armed crash/recovery pressure 31389713244 bind launcher d8aa1d0bf9783d29d53d0a5e912f09f1fa414624 to exact reproducible installed binary identities, unchanged repository state, zero terminal scopes, and the typed post-admission cleanup stage. The crash run records launcher exit 86 before fresh reconciliation. These runs do not prove V3 attestation, broker authorization, lease consumption, selected execution, receipt or archive evidence, or provider-attested separation.

The committed V3 implementation additionally passed local ARM64 OrbStack PID 1 systemd pressure through the complete protected collector and attestor. Core admitted the signed V3 profile and emitted the exact authorization request; the launcher withheld it, removed the exact scope/cgroup/child boundary, and finalized the active slot. Protected-installation drift, systemd runtime drift, and unavailable producer credentials refused with zero selected work. A forced exit after durable scope recording retained one recovery slot, and the next activation reconciled it to zero before accepting another request. The checkout sentinel, receipt store, broker decision/lease state, and terminal scope set remained empty.

Immutable Linux/x64 PID 1 systemd run 31530832876 repeats those controls against Protocol 574563d1f69a674960d0b3228c5a13b13bc42c19, Launcher c69ad3afc6afef0e260a7eeaa4f7340971db50af, and clean source-built Core 31fa95b4d28a8a4971ee3fd65c841d40e54ac4d9. Its cursor-isolated retained journals prove that installation drift, runtime-property drift, unavailable producer credentials, and the injected pre-session crash do not reach authorization. Positive and recovered invocations reach the exact authorization request, which remains withheld, then finish with the typed attestation_admitted_before_authorization_boundary_removed result. The artifact records one durable scope_attached crash slot, zero terminal slots/scopes, byte-identical repository manifests, no selected-work or .ota state, and only public verifier identity. This closes the hosted execution-disabled V3 admission gate only; it does not prove broker authorization, lease consumption, selected execution, crossing receipts/archives, or provider-attested separation.

Immutable Linux/x64 PID 1 systemd run 31561247605 proves the follow-on signed-decision boundary against exact Protocol 6a92d8db9d089e44d1980f1871bf6e90eccb9960, Launcher 77ab20aa6ed5e3dd42cc6815ba2de7cd36d543bf, and clean source-built Core b71b78ca33ea2edd7bb03ceb66c5e1e104217cd9. It distinguishes allowed, denied, stale, wrong-scope, timed-out pending, ambiguous, unavailable-proxy, protected-installation/runtime drift, and missing credential outcomes while requiring zero terminal active-slot or transient-scope residue.

The pressure peer emits bounded scenario, ordinal, decision, and decision-identity checkpoints. The launcher verifies the live pidfd-bound broker executable before and after relay traffic, and emits the complete public relay envelope only under the pressure fault feature and only after durable active-slot recording. The hosted artifact retains those envelopes together with the public signed broker responses and broker verifier binding, allowing the signed decision and Core acknowledgement identities to be re-verified after cleanup without retaining either signing key. Stale and wrong-scope controls require zero acknowledgements; timeout requires exactly one acknowledged pending decision; ambiguity requires two signed pending responses but exactly one acknowledgement. The matrix also crashes after durable scope and allowed-decision recording and requires startup reconciliation to remove each exact slot, child, cgroup, and scope before a fresh request proceeds. Artifact inspection independently re-verifies all eight public signed decisions and all five relay and admission identities. Fourteen complete before/after repository manifests are byte-identical, and no selected-work, .ota, lease, receipt, archive, private-key, or credential residue exists. That decision-only run intentionally did not prove lease consumption, selected execution, or receipt/archive evidence. The later immutable runs above close those carrier boundaries and the independently administered hardened-launcher branch. Provider attestation remains optional stronger hardening rather than a property of this carrier.

What belongs here

• the Unix launcher-session implementation;
• protected credential and broker-session handling;
• challenge-bound attestation collection;
• process and descriptor isolation;
• hardened installation and service definitions;
• protocol conformance and adversarial tests; and
• signed release artifacts, SBOMs, provenance, and operator guidance.

What does not belong here

• Ota contract parsing or semantic-scope derivation;
• repository-owned authorization or self-issued grants;
• organization approval policy or a hosted approval UI;
• shared signing keys, broker credentials, or production grants;
• a bundled authority-enabled runner image; or
• claims that the launcher governs raw shell execution outside adopted Ota chokepoints.

The authority protocol is canonically published by Ota Authority Protocol and independently verified by Ota Core. A managed broker, identity-provider integration, approval workflow, fleet administration, and audit search may be provided separately; the launcher remains independently inspectable and deployable open-source infrastructure.

Completed bounded milestone

The complete first milestone implements the Unix launcher-session carrier defined by Ota Core:

1. accept one administrator-bound local session;
2. return signed attestation bound to Ota's nonce, scope, and work-unit identity;
3. obtain one exact broker authorization and prepared lease;
4. preserve credentials and the launcher descriptor outside task processes;
5. transparently carry broker-backed atomic one-use consumption and typed refusal; and
6. prove success, replay refusal, expiry, revocation, wrong scope, broker unavailability, bounded approval timeout/cancellation/ambiguity, proof-wide transaction finalization, and archive reconciliation on a hardened Linux runner.

The proof-wide pressure lane keeps Docker control unavailable to the job principal. Its lifecycle case uses a deterministic pressure-only Compose control stub to exercise Ota-owned service selection, assertion ordering, terminal authority, and cleanup. That fixture does not claim Docker provider behavior; independent provider pressure remains a separate Core evidence boundary.

Relationship to Ota

• Ota Core owns semantic scope, admission, execution, evidence, and independent protocol verification.
• Ota Authority Protocol publishes the shared wire types, fixed domains, framing, identities, and conformance vectors.
• This repository implements the privileged launcher side of that protocol.
• The public operator reference is Broker Crossing Authority.

License

Apache License 2.0. See LICENSE.