Publisher authentication — exact detached-signature procedure

Identity and scope
------------------
Keep EZA-001-DEVELOPER-TRIAL-001 / online-distribution-001 / integration v1 and
EZA-001-P3-CONTINUITY-001 unchanged. Reuse the existing Eziah release identity:
  Public file: eziah-release-2026-01.pub
  Minisign key ID: CFC656D308ECD752
  Public key: RWRS1+wI01bGz7h6vYSR4m9shqB2/q8FiIpbY8tSgDQnhNZ4qzp+0mSA
  SHA-256 of the complete supplied public-key file:
  df3a3e0aa9f6368906f7004083e8abab76e8cb98b603ab0e9146e68abbdf0311
  SHA-256 of its 32-byte Ed25519 public key (not the Minisign envelope):
  34a12226935f6bb879514285f0b048e3be8c5b306f616ca1f32790b85ab7e17c

Local public-only validation successfully verified the original detached
MANIFEST.json.minisig against the R001-rc.9 manifest, SHA-256
fc44b015cbf152aef4e4cc25bc0bdc6d58f6763a0af871b81795de04e32f8f3e.
Its trusted comment says:
  Eziah EZA-001 R001; candidate EZA-001-R001-rc.9; MANIFEST.json
That original signature authenticates those original manifest bytes and files
bound by its inventory. It does NOT cover CONTINUITY-001, integration v1, this
wrapper, the developer tar or the later Linux evidence. Do not reuse it here.
Fixture receipt keys are not publisher release keys.

NEW exact signing target: public/RELEASE-MANIFEST.json
NEW detached signature: public/RELEASE-MANIFEST.json.minisig
The new manifest binds the distribution tar, complete fresh-Linux evidence tar,
public notes, prerequisites, quick-start, limitations, result instructions,
public key copy and checksum inventory by exact SHA-256 and size.
The signature is a separate file outside the unchanged distribution archive.
No new key generation, rotation, identity change or frozen-manifest editing is
part of this procedure. The preceding staging manifest was owner-signed and its
Minisign signature verified with the existing Eziah key above. That manifest and
signature are retained only as superseded local staging evidence under
../audit/superseded-local-staging/public/. They do not authenticate the corrected
manifest. This final corrected snapshot awaits a fresh owner-controlled signature.

Publication trust anchor
------------------------
The release owner's independently authenticated Eziah channel, preferably the
existing owner-controlled HTTPS eziah.dev release-signing page, must identify
the publisher as Eziah AI / Montrel Hutto and publish the full public key above,
key ID, file digest, signing scope and exact verification commands. Preserve
any established public-key URL; its exact current URL and status were not
verified offline. Do not invent a replacement URL or rely only on a key shipped
beside the download. Compare with a previously trusted key or obtain owner
confirmation through a separately authenticated channel. The owner must confirm
that the existing key remains authorized and uncompromised before signing.
No current revocation/compromise status or control of eziah.dev was checked here.

Human release owner ONLY — not executed by the preparing agent
-------------------------------------------------------------
Use an already trusted Minisign installation. Review the public files and
../audit/SIGNING-HANDOFF.txt. That handoff supplies the exact target digest;
compare it over an owner-trusted channel. Run in a human-controlled shell:

  cd '/Users/eziahai/Desktop/EZA-001-P3-Independent-Verification-001/publication-gate-001-final/public'
  shasum -a 256 RELEASE-MANIFEST.json
  python3 -I -B verify_publication.py

Require the manifest digest to equal the handoff and the verifier to report PASS.
The verifier checks integrity only; inspect its small source before running it.
Use SHA256SUMS only as an inventory, never as a substitute for authentication.
Ensure RELEASE-MANIFEST.json.minisig does not already exist. Do not overwrite a
previous signature or silently repackage after this point.

The owner supplies the key path locally, outside any agent session. Replace the
placeholder below on the owner's machine only; do not paste that path, key or
passphrase into chat. The preparing agent has not located or accessed this key.

  EZA_OWNER_SIGNING_KEY='/owner-controlled/path/to/existing-release-signing-key'
  test ! -e RELEASE-MANIFEST.json.minisig && \
  minisign -S -m RELEASE-MANIFEST.json -s "$EZA_OWNER_SIGNING_KEY" \
    -x RELEASE-MANIFEST.json.minisig \
    -t 'Eziah EZA-001-DEVELOPER-TRIAL-001; online-distribution-001; experimental; Publication Gate 001'

Immediately verify with the separately confirmed public key, and require success:

  minisign -Vm RELEASE-MANIFEST.json -x RELEASE-MANIFEST.json.minisig \
    -P 'RWRS1+wI01bGz7h6vYSR4m9shqB2/q8FiIpbY8tSgDQnhNZ4qzp+0mSA'
  python3 -I -B verify_publication.py

Equivalent public-file verification, after authenticating that file independently:

  minisign -Vm RELEASE-MANIFEST.json -x RELEASE-MANIFEST.json.minisig \
    -p /absolute/path/to/trusted/eziah-release-2026-01.pub

Keep the reviewed files byte-identical. Any payload or manifest change invalidates
this handoff and requires a fresh review and signature; do not repair checksum
files to conceal changes. The original frozen identities remain unchanged even
when a later publication wrapper is prepared.

Later publication is a separate human-controlled gate: publish the exact public/
contents plus the new detached signature, key/trust-anchor information and the
acceptance record. Do not publish the internal parent package, quarantined wheels,
VM image or runtime. Verify the actual downloaded bytes/signature on a clean
recipient system before announcing availability. No upload or website action is
included in this procedure's execution at Publication Gate 001.

Recipient — authenticate before package execution
-------------------------------------------------
Obtain the expected full public key independently as described above. Use the
Minisign -Vm ... -P command above FIRST from the downloaded public directory.
A valid signature authenticates RELEASE-MANIFEST.json. Then use an already
trusted Python installation and this small bootstrap to hash-check the verifier
before executing the received verifier itself:

  python3 -I -B - <<'PY'
import hashlib, json
from pathlib import Path
m = json.loads(Path('RELEASE-MANIFEST.json').read_bytes())
rows = [r for r in m['files'] if r['path'] == 'verify_publication.py']
assert len(rows) == 1
p = Path('verify_publication.py')
assert p.is_file() and not p.is_symlink()
b = p.read_bytes()
assert len(b) == rows[0]['bytes']
assert hashlib.sha256(b).hexdigest() == rows[0]['sha256']
print('Authenticated verifier bytes')
PY
  python3 -I -B verify_publication.py

Continue to QUICK-START.txt only after all commands succeed. The verifier requires
exact payload membership, checks every byte count/hash and the checksum sidecar,
and permits only the manifest, its digest companion and optional detached
signature as extras. Run it in the clean public download directory, not amid
other downloads or extracted trees. Signature validity alone is not correctness.
The digest companion is a convenience check; it has no independent trust value.

Command syntax was checked against installed Minisign 0.12 help and original
SIGNING.md/VERIFY.md. No signing command was run and no private key was inspected.