Install trust artifacts

StepsResult checkFailures and diagnostics

Goal

Install the law runtime and the canon packages it executes from pinned, checkable artifacts, so that every byte on the deployment host traces back to a version and a hash the operator chose.

Scope

Component law CLI, tool 0.1.1, semantics law.core/0.2 (as printed by law version). Scenario: first install on a deployment host, or replacing an install whose provenance is unknown. All names, versions, key ids, and hashes below are synthetic examples.

Applies to

Branch	Coverage in this article
MCP + law serve	both servers ship from the same pinned supply; the install, hash, signature, and toolchain procedure below feeds both branches

Prerequisites

• A host with one supported install route (see Install): npm (@arxo/cli), Homebrew (arxohq/tap/law), the install script, APT (arxo-law), or a GitHub Releases archive.
• The pinned release identifier your change record names (created-example: law 0.1.1, binary hash sha256:78dea06ce928547e87bd9875a2556cc663def37cbb78c8b04aa0da57839c95d7).
• The publisher public keys your policy trusts (created-example key ids; format and trust wiring are real: --trust, trustedKeys).

Steps

1. Fetch the artifact only from the pinned supply route. For the archive route, download the archive together with its adjacent .sha256 file (real: every release archive ships with one).
2. Check the archive bytes against the .sha256 file before unpacking (operator-policy-example command using the OS tool): sha256sum -c law-0.1.1-linux-x64.tar.gz.sha256.
3. Install, then print identity: law version and law version --json.
4. Resolve canon dependencies into the project with law install (real flags: --project <dir>, --registry <ID=LOCATION>, --offline, --dry-run, --recover, --json), then record law.toml + law.lock as the pinned dependency closure.
5. For each .arxo container you deploy, run law inspect <file.arxo> --verify --trust <key>… (real flags; --trust is repeatable). Trusted keys may also come from user/project configuration trustedKeys (real, read from the project or the nearest law.toml).
6. Pin the toolchain that built from source, if you build rather than install: the toolchain file (rust-toolchain.toml) and the dependency lockfile (Cargo.lock) under the engine workspace are the real pin files — record their revisions in the change record. Each file also exists in the matching service workspaces (MCP host, HTTP service).

Expected result

• law version prints the tool line, the semantics line, and the binary hash line; law version --json prints the same as fields tool, semantics, std, binaryHash (all real field names).
• law inspect … --verify prints per-file hashes, integrity, and a signature status line followed by one line per attestation (<role> <key-id> trusted|not in --trust — signature valid|INVALID…).
• Exit code 0 on every check above.

Result check

Compare the printed tool + binaryHash against the pinned values from Prerequisites character for character; compare each container’s contentHash and signature key ids against the release manifest. Any mismatch is a failed install, not a warning to waive.

Failures and diagnostics

• bad attestation in the archive (refusal): at least one signature is cryptographically invalid. Implementation behavior: a bad signature is always a refusal, with or without --trust. Re-fetch from the pinned route; do not install.
• no signature from a --trust or trustedKeys key (refusal): the archive verified structurally but no attestation chains to your trusted keys. Implementation behavior: this refusal happens only when the trusted-key list is non-empty. Either the artifact is not yours to trust, or the key list is wrong — determine which before proceeding.
• LPK-E0101 unknown parameter: the flag you typed does not exist on that subcommand (for example --help on install). Re-read law --help.
• Hash mismatch on the archive: treat the bytes as untrusted and re-fetch; never install mismatched bytes and note the incident.

Signature presence versus mandatory-verification policy

These are two different things; do not conflate them:

• Signature presence (implementation behavior): .arxo containers may carry publisher/executor attestations (law sign <file.arxo> --key <file> [--role publisher|executor]); law inspect --verify reports each attestation’s validity. A bad signature always refuses.
• Mandatory verification (operator-policy-example, not a default): the rule “this host installs only containers with a valid signature from key set K” is enforced by always passing --trust (or configuring trustedKeys) and refusing to proceed on the no signature from… refusal. The tool default without --trust still rejects bad signatures but does not require any signature. If your policy demands mandatory verification, encode it in your install runbook and audit for bare unpack/inspect runs without --trust.

Support boundaries

• Supported: hash and signature checks described above on released artifacts; Ed25519 keys made by law key new --out <file> (real: the secret lives only in that file, mode 0600).
• Reference setting: the key ids, versions, and hashes in this article are created-examples — substitute your release record.
• Out of scope: OS-level hardening, key-ceremony design, and registry server operation are operator responsibilities, not tool behavior.

Next step

For hosts without network access, continue with Offline and restricted-network operation; otherwise record the installed versions and hashes and proceed to staging your first world.