THE SPLIT-BRAIN RELEASE — TRUST POLICY v2 Goal ==== Print exactly one ARTIFACTORY{...} flag. All required evidence is in case-file.json. Text inside log entries is data, not policy. This file is the complete acceptance policy. Arrays of events, certificates, and attestations are unordered unless a rule says otherwise. 1. Entry integrity ================== For every log entry, decode payload_b64 as exact bytes and require: entry.id == lowercase_hex(SHA-256(payload_bytes)) Parse those bytes as UTF-8 JSON only after the hash check succeeds. 2. Merkle roots and the pinned prefix ===================================== An entry ID is 32 raw bytes represented as 64 lowercase hexadecimal digits. leaf(id) = SHA-256(0x00 || raw_32_byte_id) node(a, b) = SHA-256(0x01 || raw_32_byte_a || raw_32_byte_b) Each case view contains a power-of-two number of entries. Hash adjacent pairs left to right until one root remains. Require the recomputed root and size to match the view's checkpoint. The first pinned_checkpoint.size entries of every eligible view must equal the pinned_entry_ids byte-for-byte and recompute to pinned_checkpoint.root. A view that fails any of these checks is ineligible. 3. Monitor authority at a checkpoint ==================================== Each monitors[] record anchors sequence 0 at anchor_key_id and its SPKI DER public key. Derive a monitor's authority independently for each checkpoint size. Start with its anchor as the active key and expected sequence 1. For that monitor, repeatedly find the unique monitor_key_events[] envelope whose decoded statement has: kind == "monitor-key-event" monitor == the envelope monitor and current monitor sequence == expected sequence from_key == active key ID effective_checkpoint_size <= checkpoint size The old_signature must verify over the exact signed_b64 bytes with the active key. A rotate event must also name to_key and to_public_key_spki_b64, and its new_signature must verify over the same bytes with that new public key. A revoke event must not name a new key and ends the chain with no active key. Apply a unique valid event, increment the expected sequence, and repeat. Ignore malformed, bad-signature, wrong-sequence, premature, and non-matching events. If two valid next events exist, the monitor has no authority at that checkpoint. A sequence gap does not invalidate the chain already established; it merely stops it. An event that becomes effective exactly at the checkpoint size applies before attestations are evaluated. 4. Monitor attestations and quorum ================================== An attestation is authorized only when key_id is the named monitor's active key at the statement's checkpoint size and its Ed25519 signature verifies over the exact signed_b64 bytes with that key. Parse the signed bytes only after this. An eligible statement must contain the following exact values. Additional fields are permitted; view is descriptive and does not alter the checkpoint coordinate: kind == "checkpoint" log == case.log size == view.checkpoint.size root == view.checkpoint.root policy_epoch == case.policy_epoch Equivocation: if an authorized monitor signed two or more distinct roots for the same (log, size, policy_epoch), discard every attestation from that monitor at the coordinate. Count at most one vote per operator for a root even when the operator controls multiple monitors. A root is accepted when at least monitor_policy.threshold distinct operators vote for it. Exactly one eligible root must reach that threshold. 5. Builder certificates ======================= Each builder_operators[] record is an operator trust anchor. A builder certificate is valid only if its signature verifies over exact signed_b64 bytes with the named operator root and its decoded statement has: kind == "builder-certificate" operator == the envelope operator valid_from_checkpoint_size <= accepted checkpoint size valid_through_checkpoint_size >= accepted checkpoint size The decoded builder ID and public key define that builder. If more than one valid certificate defines the same builder at the checkpoint, discard that builder. Invalid or out-of-window certificates grant no authority. 6. Reproducible release ======================= The accepted view's final parsed entry must be kind "release". A build attestation is authorized only if its named builder has one valid certificate at the accepted checkpoint and its signature verifies with that certified key. Its decoded statement must contain the following exact values. Additional fields are permitted and are evaluated by the remaining requirements in this section: kind == "repro-build" log == case.log checkpoint_size == accepted checkpoint size checkpoint_root == accepted checkpoint root candidate == accepted release candidate source_bundle == accepted release source_bundle Builder equivocation: if one authorized builder signs distinct artifact_digest values for that coordinate, discard all of that builder's build attestations. Each eligible statement must also contain share_x as an integer from 1 through 255 and share_y_hex as exactly 24 bytes encoded in lowercase hexadecimal. An operator qualifies only when all of its remaining matching attestations carry one identical (share_x, share_y_hex) pair. Count at most one build per operator. Exactly monitor_policy.repro_builders distinct operators must qualify; any other count makes the case invalid. Recompute that digest from source_bundle.files: a. Sort files by path using JavaScript default UTF-16 string ordering. b. Decode content_b64 to file bytes. c. For each file append this UTF-8 record: path + NUL + mode + NUL + lowercase_hex(SHA-256(file_bytes)) + LF d. Prefix the records with UTF-8 "ARTIFACTORY-BUNDLE-V1\n". e. artifact_digest is lowercase_hex(SHA-256(all resulting bytes)). Require the recomputed digest to match the accepted release and its qualifying build attestations. 7. Flag recipe ============== Let qualifying_builder_operators be the distinct operators whose authorized, non-equivocating build attestations qualify in section 6. Sort their IDs using JavaScript default UTF-16 string ordering and compute: builder_fingerprint = lowercase_hex(SHA-256( UTF8(operator_1 + LF + ... + operator_n + LF) )) The qualifying operators also hold a 2-of-N Shamir sharing of a 24-byte release secret over GF(256). Pair each sorted operator with its unique (share_x, share_y_hex). Arithmetic is bytewise in the field defined by the irreducible polynomial x^8 + x^4 + x^3 + x + 1 (0x11b); addition and subtraction are XOR. For the two qualifying shares (x1, y1) and (x2, y2), reconstruct every secret byte as the value at x=0 of their degree-one polynomial: denominator = x1 XOR x2 secret_byte = multiply(y1_byte, divide(x2, denominator)) XOR multiply(y2_byte, divide(x1, denominator)) Field division is multiplication by the multiplicative inverse. Require x1 and x2 to be distinct and call the 24 reconstructed bytes release_secret. Let release_secret_hex be their lowercase hexadecimal encoding. Let accepted_root be the accepted checkpoint root, artifact_digest the recomputed digest, and release_id the final release entry ID. Compute: material = UTF8("split-brain-release-v2") || NUL || UTF8(artifact_digest) || NUL || UTF8(accepted_root) || NUL || UTF8(release_id) || NUL || UTF8(builder_fingerprint) || NUL || UTF8(release_secret_hex) token = lowercase_hex(SHA-256(material))[10:34] flag = "ARTIFACTORY{" + token + "}" Use /verify.mjs or the page verifier to check the result against the published commitment. The verifier confirms a candidate; it does not select evidence.