Bind published artifact hashes to authenticated source commits - #382
Conversation
Describe the separate evidence-publication custody correction, exact source binding, refusal invariants, focused staging tests and prerequisite publication constraint. This is Phase A for Delivery #381; implementation remains pending its own same-task semantic approval. Package contract PASS (0 failures); existing publication and admission tests 70 PASS. No runtime, policy, workflow or artifact bytes changed.
|
Phase A design review — Delivery #381 / PR #382 at Two bounded AI reviews of the concrete RFC reported zero design Blockers, zero added Follow-ups and zero Preferences. Both reviewed RFC SHA-256 The review checked the high-risk floor and P01-P06: trusted path ownership, exact authenticated execution-commit reads through the existing reader, one required ordered expected hash list for both source runs and staged revalidation, no fallback or execution of fetched content, unchanged custody gates, and the main-based prerequisite preserving configured artifact bytes. The bootstrap constraint permits this PR's own evidence to be published by existing default policy; candidate policy cannot substitute for trusted publication. Code excellence: one existing reader, one required validator input, deletion of the wrong-revision calculation, no duplicate source or durable state, and focused staging tests using valid complete fictional envelopes. Scope stays within evidence-publication custody, separate from PR #380. Actual cheap checks at the design source: package contract PASS, 0 failures, including architecture; whitespace PASS; existing publication/admission suite 70 tests PASS in the local CPython 3.12.13 environment, using fictional fixtures and temporary directories. No database was used. The 70 unchanged tests characterize existing behavior and do not demonstrate that the unimplemented correction works. The sole source change is the 190-line RFC. Policy, workflow, configured artifacts, baseline inputs and runtime remain unchanged. No expensive admission or hosted baseline has been requested for this Phase-A-only head. Semantic decision Next: obtain that distinct same-task approval, implement the complete slice in this same PR, then follow all existing review, admission, publication and final human acceptance gates. |
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
PR #382 — Phase A review
Verdict: changes required before semantic approval. One in-scope design blocker.
Reviewed head: f08cd7d711617c5635cca2f8de1a9852f61976ec
Base: ff092c414db9fa24dbd6ab86c7722db89e0c95b5
The PR is draft and design-only: its sole change is the 190-line authenticated-source-artifact publication RFC. No publisher implementation or new tests exist at this head. This is a content/design review, not semantic approval, baseline admission, implementation acceptance, merge authorization or deployment authority.
B1 — The proposed reader reuse does not establish that the authenticated response is a source file
Priority: P2 — must resolve in Phase A.
Affected design: RFC's proposed custody sequence, steps 3–4, and invariants P02/P03.
Owning implementation: _download_authenticated_source_file() in conformance/evidence_publication_policy.py.
The design instructs staging to reuse the existing reader and hash its returned bytes as the expected artifact content. However, that reader establishes only a checked request, HTTP 200, unchanged final URL, and a nonempty bounded response. It does not establish the repository object's kind or distinguish raw file content from an API metadata response.
Sources: proposed RFC and existing reader/publisher.
That distinction matters for this endpoint. GitHub's Contents API serves both files and directories; its documented responses include directory listings, metadata for unresolved symlinks, and submodule descriptions. Requesting a trusted pathname at an exact commit does not, by itself, prove that the pathname resolves to the expected kind of file. See GitHub's Contents API documentation.
The resulting source-level counterexample is:
A configured artifact path is replaced by a directory at the admitted commit.
The Contents API returns nonempty directory metadata.
The existing reader accepts those response bytes.
The proposed implementation hashes that metadata as the expected artifact.
Both producer envelopes claim that same hash.
Exact hash-list equality does not establish that an artifact file existed.
This falls within the RFC's declared threat model: source content and producer envelopes are untrusted, and an author may fabricate internally consistent claims. It does not require compromising trusted publisher policy, credentials or GitHub.
The reader's existing use for the test inventory does not establish safety for this new use. Inventory bytes subsequently undergo _load_source_test_inventory() validation against the expected inventory document. The proposed verified-artifact path instead treats the bytes solely as hash input, so that downstream structural check does not protect it.
Evidence: I executed the copied reader against three synthetic HTTP-200 responses representing a directory listing, unresolved-symlink metadata and submodule metadata. It accepted all three unchanged. This confirms the missing distinction in the reader; it is not a live GitHub response capture or an end-to-end publication exploit. The isolated reader probe ran on Python 3.13.5, not the pinned Python 3.12.13 environment. Supplemental probe source and results were supplied in the originating review conversation; no repository test execution is claimed by these probes.
Smallest controlled correction: amend the design to require an authenticated, commit-bound proof that each configured path resolves to a supported source-file object before its content becomes an expected artifact hash. Define the symlink policy explicitly and refuse unsupported directories, submodules and unresolved links. Keep this within the existing source-reading path and the same repository/commit authority; do not introduce checkout, source execution or a fallback.
Do not solve this by rejecting bodies merely because they look like metadata: the actual artifacts are JSON. The distinction must come from authenticated object information or an equivalent provider guarantee, not a content-shape guess. The current configured artifacts are the capability manifest and ActiveArtifactSet JSON files.
Add a complete staging negative in which both producer envelopes contain matching hashes of the non-file response and their comparison has been recomputed. It must refuse specifically because the source object is unsupported—not because another envelope field is invalid. Adjust the "exactly one read per path" test requirement if obtaining the necessary object proof requires additional bounded metadata reads.
The underlying correction is otherwise well targeted
The reported revision mismatch is real in the code. The producer hashes ROOT / path; the publisher currently hashes POLICY_ROOT / path. Replacing only the latter expectation with an independently established hash of the executed source is the correct direction. Keeping path selection and ordering under trusted configuration avoids handing the producer a new path-selection authority.
The execution coordinate already reaches the correct boundary. The publication workflow supplies steps.publisher-start.outputs.execution_merge_sha to stage-conformance, rather than taking a revision from the producer envelope. The design can preserve that existing authenticated source chain.
One required expected list is preferable to parallel calculations. Reusing it for both producer validations and staged revalidation preserves one comparison rule. Deleting the old policy-root calculation, without a fallback, prevents the original defect from surviving in a secondary path. The current staging function has both validation call sites that the RFC identifies.
The bootstrap plan avoids the dependency loop. Keeping this prerequisite based on main, with both configured artifact files and policy-owned baseline inputs unchanged, permits its own evidence to go through the existing publisher. Importing #380's changed manifest here would recreate the known failure. Candidate tests must prove the changed-source behavior; the prerequisite's eventual receipt must still come from trusted default policy.
Required implementation companion — refresh the transitive workflow pin
There is one mechanical dependency beyond the publisher's own policy-file hash:
evidence_publication_policy.py changes
→ policy hash in evidence-publication.yml changes
→ workflow hash in conformance.yml changes
conformance.yml pins the publisher workflow's bytes, and kernel/tests/test_postgresql_native_evidence.py checks that relationship. Updating only the policy hash inside evidence-publication.yml would leave the transitive pin stale.
This is not a second design blocker or separate Delivery. It is a required mechanical companion within the same custody correction. The RFC already treats expected paths as predictions and requires the existing workflow/pin checks.
Verification and disposition
I inspected the RFC, current producer/publisher paths, authenticated reader, staging fixture, configuration, workflow bindings and current-head lightweight job results. Lightweight run 34250261926 completed successfully. I did not rerun repository tests, the package checker or a hosted baseline.
The reported 70 passing publication/admission tests are unchanged tests: they characterize the existing implementation, not the proposed fix. The PR's design-review record makes that distinction.
Resolve B1 in the source-file contract, then re-review the affected design before presenting the semantic-approval card. This is an implementation/evidence-policy correction; no active OFARM baseline-law amendment is needed. Keep #380's kernel changes and its eventual fresh verification sequence separate.
No semantic approval, implementation acceptance, baseline admission, merge authorization or publication bypass is supplied by this review.
Withdraw the version-1 card after review B1 and preserve its design as history. Define version 2 with exact commit/tree/blob proof, explicit no-symlink policy, bounded shared source reading, complete non-file staging negatives and both transitive workflow pins. Design-only revision for Delivery #381 and PR #382. Publisher implementation still requires later exact same-task version-2 approval. Package contract PASS (0 failures); unchanged publication/admission tests 70 PASS; prior environment failure and existing extraction FAIL (2) retained.
|
Scoped Phase A repair review — PR #382 at Review 5168801319 correctly identified B1. Version 1 and its card are withdrawn. The original RFC text remains unchanged below its withdrawal notice; RFC v0.2 is the proposed replacement. The revised design closes B1 at the contract level: one shared reader proves exact commit → selected nonrecursive trees → terminal regular blob, rejecting all selected parent/terminal symlinks, submodules and directory terminals. It validates metadata identity/shape, mode and size, then fetched bytes against the proved blob length and Git object ID. Metadata-looking regular JSON stays valid. HTTP bounds, strict decoding, authenticated source authority and exact comparisons remain; no parallel reader, checkout or fallback. Two bounded AI reviews checked that correction and affected invariants against provider documentation, current reader/staging code and both transitive workflow pins. They confirmed the committed v2 hash Focused evidence requirements now include complete staging negatives with matching non-file metadata hashes in both envelopes and a recomputed comparison; parent and terminal symlinks; submodules; missing/ambiguous/truncated/malformed object information; byte-size/object-ID mismatches; exact bounded requests; and lawful regular metadata-looking blobs. All tests remain fictional and local before hosted gates. Both required mechanical pins are explicit: Actual checks: package contract PASS, 0 failures, including architecture, before commit; whitespace PASS; 70 unchanged publication/admission tests PASS in 1.916 seconds, with no database. Initial package FAIL (2) from a disappeared temporary environment (missing jsonschema/Ruff) is preserved. A new task-owned CPython 3.12.13 environment with repository-version-pinned checker dependencies passed pip check and the package rerun. Native wheel records are supplemental, not locked Linux equivalence. Extraction still reports its two existing missing review records; no applicability or gate is waived. Only design documents changed. Publisher implementation and new regression code do not exist yet. The decision is OFARM2-SOURCE-ARTIFACT-PUBLICATION-001 version 2 and requires a complete same-task card plus later exact user approval. No new admission, expensive baseline, receipt waiver or merge authority is supplied here. Scope remains evidence-publication custody; PR #380 remains separate. Next: obtain version-2 semantic approval, implement the complete slice in this same draft, then follow all existing review, publication and final human acceptance gates. |
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
PR #382 — Phase A review of RFC v0.2 at 3d3b289
Verdict: one Blocker, all of it in the document's own evidence reporting. The
version-2 security contract itself holds — I could not break it in 26 cases.
Reviewed head: 3d3b28924b19d813d36e9b5e663a2b89c0882f4d
Base / current main: ff092c414db9fa24dbd6ab86c7722db89e0c95b5 (confirmed live)
RFC v0.2 SHA-256: 0437519d885e89803608142c4a16f23a62c613a7fbde725f89884f1f173d8409
RFC v0.1 SHA-256 at f08cd7d: d9e6fe369317098eaccbc05341dd2d68a86b474211ae5b7cd7001b3bdd2861ca
RFC v0.1 SHA-256 at this head: 6aa2e8fa604c4c13fe5a8d9f9016fdb228f083b361fd30ead3490664e201b8cc
All five digests recomputed from a fresh anonymous clone plus
git fetch origin refs/pull/382/head, not from the working checkout. The first two
reproduce the digests claimed in the PR's two design-review comments exactly.
How this pass is positioned
This is the first review object on 3d3b289. Review
B1 was
submitted against f08cd7d, the version-1 head. Two further design reviews are
recorded only as issue comments
(5588353325
at v1,
5624362132
at v2), both reporting zero design Blockers. I read those after measuring, and
this pass reaches a different conclusion on one point.
All reviews on this PR, including this one, are authored by samovers, who is also
the PR author. GitHub refuses APPROVE and REQUEST_CHANGES from the author (422),
so every one of them is a COMMENT. A self-review almost certainly does not satisfy
an independent-review gate. Do not let the count of reviews here stand in for
independent standing.
Diff at this head: two files, +485/-0, both under docs/rfcs/. 3d3b289 adds
v0.2 (290 lines) and prepends a 5-line withdrawal banner to v0.1 — the v1 body is
otherwise byte-identical, as comment 5624362132 states. No implementation, tests,
workflow pins, kernel, manifest or database changes exist at this head.
Blocker 1 — the RFC states a probe environment that the review it cites explicitly denies
Violated rule: AGENTS.md §8 — "Honest reporting: failing tests are reported as
failing; design fixtures are never presented as executed evidence; skipped steps are
named."
Location: RFC v0.2, "Version-2 correction to the withdrawn design", paragraph 1.
The RFC writes:
The local Python 3.12.13 reader probe accepted three fictional
directory/link/submodule metadata responses; this was not a live provider capture
or an end-to-end publication exploit.
Review B1, which is the cited source of that probe, writes the opposite:
The isolated reader probe ran on Python 3.13.5, not the pinned Python 3.12.13
environment.
3.12.13 is the interpreter pinned in conformance/review_baseline_config.json
(requiredEnvironment.pythonVersion, and knownGreenBaseline.observedInRun). The
RFC therefore promotes a probe that its own source flagged as off-pin into a
probe on the pinned environment. B1 also noted the probe used a copied reader, not
the module.
This is small in words and large in kind. The document's entire subject is what may
be presented as evidence and under whose authority; it is the artifact a semantic
approval binds. A design that upgrades the provenance of its own supporting evidence
by one sentence is exactly the failure mode the custody correction exists to prevent.
Every other factual claim in this RFC that I checked reproduced (see the table below),
which is why this one stands out rather than blending in.
Smallest acceptable fix — pick one:
- Restate the sentence as B1 wrote it: an isolated copied-reader probe on Python
3.13.5, explicitly not the pinned environment; or - cite a real 3.12.13 run.
For (2), I have now produced one, so no new work is needed to take that route. I
built CPython 3.12.13 from the upstream tag (v3.12.13, ./configure --prefix=…,
make -j4, make install; the interpreter self-reports
Python 3.12.13 (main, Sep 10 2026, 20:32:53) [GCC 11.4.0]) and drove the real
module at this head — conformance/evidence_publication_policy.py imported by
path, no copied code — through its own response_factory seam:
interpreter: 3.12.13 (main, Sep 10 2026, 20:32:53) [GCC 11.4.0]
module: …/pr382/conformance/evidence_publication_policy.py
MAX_SOURCE_INPUT_BYTES: 8388608
ACCEPTED directory listing: 264 bytes, sha256=cae4cfa35c7a0d2479b4c61421a1abb02a939ad8508fee2dbc680473bba29bd4
ACCEPTED unresolved symlink metadata: 242 bytes, sha256=08df3a2d740b60d030a488e9c18bacf3aed8b6df7399df8621b0821db9aa25c7
ACCEPTED submodule metadata: 286 bytes, sha256=5a9795bb98c81efb8607782b51120f3f7eb0e4c3cc0cefef0ee41ede1089f19f
ACCEPTED ordinary regular file (positive control): 49 bytes, sha256=660acb61abcd92104e4c6ec6e9b51ff6249663d654785b5a0c5bd5903a400e55
Byte-identical digests on 3.12.3 beforehand, so the interpreter was never
load-bearing for the conclusion. B1's finding is correct and reproduces on the pinned
interpreter against the real module. The defect is the reporting, not the claim.
Caveats that must travel with any citation of the above: the payload shapes come
from GitHub's Contents API documentation, not a live capture; the run went through
the injected response_factory, so no TLS, redirect handler or real HTTP was
exercised; and my build ran on linux-aarch64, while the pinned baseline is
x86_64 / ubuntu-24.04.
Does version 2 actually close B1? Yes — 26/26, including B1's own counterexample
I did not want to assess the supported-file contract by reading it. I implemented it
literally — steps 1–4 of "Supported-file contract within the existing reader" — as a
reviewer's oracle, reusing this head's real _checked_api_url, _checked_repository,
_checked_source_path, _decode_json_object, _object, _array,
DOWNLOAD_CHUNK_BYTES and MAX_SOURCE_INPUT_BYTES, and drove it with fictional
commit/tree/blob responses dispatched by exact request URL. On Python 3.12.13:
--- positive controls (must be ACCEPTED) ---
[ok ] ACCEPTED regular file 100644, changed source bytes (reads=4)
[ok ] ACCEPTED executable file 100755 treated only as data (reads=4)
[ok ] ACCEPTED regular JSON blob whose bytes look like directory metadata (reads=4)
--- RFC's declared negatives (must be REFUSED) ---
[ok ] REFUSED directory terminal (B1's counterexample): selected terminal object is not a file
[ok ] REFUSED submodule terminal 160000: selected terminal object is not a file
[ok ] REFUSED terminal symlink 120000, unresolved: not a regular file
[ok ] REFUSED terminal symlink 120000 whose target is a real in-repo file: not a regular file
[ok ] REFUSED parent component is a symlink: selected parent component is not a directory
[ok ] REFUSED parent component is a submodule: selected parent component is not a directory
[ok ] REFUSED selected terminal name missing: selected tree entry is missing or duplicated
[ok ] REFUSED duplicate selected entries with the same name: missing or duplicated
[ok ] REFUSED truncated root tree: source tree response is truncated or unproven
[ok ] REFUSED root tree response omits truncated: truncated or unproven
[ok ] REFUSED commit object returns a different sha: source execution commit identity differs
[ok ] REFUSED tree object returns a different sha: source tree identity differs
[ok ] REFUSED mode 100644 but type is tree: selected terminal object is not a file
[ok ] REFUSED terminal size is boolean True: selected terminal size is not an integer
[ok ] REFUSED terminal size is zero (empty regular file): size is out of range
[ok ] REFUSED declared size differs from raw byte count
[ok ] REFUSED raw blob bytes substituted (same declared size): object identity differs
[ok ] REFUSED blob fetch redirected to another final URL
[ok ] REFUSED blob fetch returns HTTP 404 / fails at transport
[ok ] REFUSED oversized tree metadata (> 8 MiB)
[ok ] REFUSED malformed tree metadata (JSON array, not object)
[ok ] REFUSED duplicate JSON keys in tree metadata: JSON contains a duplicate object key
26/26 cases matched the RFC's stated outcome
Four results are worth naming individually.
- B1's exact counterexample dies before any hashing. A directory at the configured
artifact path refuses at the tree entry, three reads in, before the blob request —
so no bytes ever reach the expected list, and matching producer envelopes cannot
rescue it. - A symlink whose target is an ordinary in-repository file also refuses. This is
the case the Contents API silently dereferences and the one the RFC promises to
refuse; the mode check on the terminal entry is what makes the promise real. - The "regular JSON blob whose bytes look like API metadata" positive control
passes. The contract discriminates on provider object information, never content
shape — the constraint B1 attached to the fix is satisfied. - The substituted-blob case refuses at Git object identity, not at size. This is
the check that makes the raw fetch inert: the reader would rather fail than return
bytes it did not prove.
Read budget reproduces exactly. A depth-2 path spends four reads:
…/git/commits/1111111111111111111111111111111111111111
…/git/trees/2222222222222222222222222222222222222222
…/git/trees/3333333333333333333333333333333333333333
…/git/blobs/034ba4751a2bba8d345cbb5e95eb3cf10b570463
depth-2 path spends 4 reads -> three configured paths spend 12
The three trusted paths — conformance/review_baseline_test_inventory.json and the
two verifiedArtifacts — are all two-component, so d+2 = 4 each and 12 total.
The RFC's correction of the withdrawn three-read assertion is arithmetically right.
Every fictional tree entry and tree response in my fixture carried a
"url": "https://evil.invalid/…" field. None was ever requested: all 12 URLs were
constructed locally from the checked API URL, repository and validated object IDs.
The RFC's no-response-URL-following rule is not just stated, it is structurally
unavoidable in the shape it specifies.
Follow-up 1 — the same wrong-revision comparison survives for four other inputs
Deleting the POLICY_ROOT calculation for verifiedArtifacts does not remove the
defect class from _validate_baseline_evidence. At this head, expected_inputs
(lines 1071–1094) still hashes four more paths out of the publisher's own checkout:
config POLICY_ROOT / conformance/review_baseline_config.json
dependencyLock POLICY_ROOT / requirements-review-baseline.lock
packageManagerLock POLICY_ROOT / requirements-review-pip.lock
schema POLICY_ROOT / kernel/schema.sql
while the producer (conformance/run_review_baseline.py:784-787) hashes each under
ROOT, i.e. the executed source. testInventory is already exempt: its expectation
is source_inventory_sha256. So after this correction, a PR that lawfully changes
kernel/schema.sql or either lock file reproduces this PR's refusal in a different
field.
This is not a Blocker and not scope for this PR. P04 declares those checks
policy-owned and preserved, and there is a principled reason: a producer that could
move its own lockfile or schema expectation would be choosing its own verification
environment, whereas verifiedArtifacts are attested data. But the RFC never states
that criterion, and its problem statement is written generally ("A legitimate change
to a verified artifact therefore prevents publication"). One sentence naming the
rule — policy-owned inputs stay pinned to the trusted checkout; attested source
artifacts bind to the execution commit — would keep the next reader from concluding
the class was fixed. Record the residual refusal class as separate Delivery work if
and when it bites.
It does not block PR #380. I pulled #380's file list: 14 files, of which
profile_si_ffs/OFARM_Capability_Manifest_si_ffs_pilot_v0_1.json (+3/-2) is a
configured verifiedArtifact — the exact blocked case — and
conformance/review_baseline_test_inventory.json (+682/-2) is the already-exempt
inventory path. #380 touches none of the four paths above. So this prerequisite is
sufficient for the refusal it was written for.
Preferences (non-blocking under EXC-007)
P1 — P01's stated observable is no longer producible. The invariant table's
evidence column for P01 reads "Recorded requests contain only trusted paths."
Under version 2 every request is object-ID addressed; my instrumented run recorded
0 of 12 request URLs containing a repository path. The RFC's test plan already
specifies the correct replacement ("assert the exact bounded request sequence"), so
nothing is lost — but the sentence is carried over from version 1 and, taken
literally, asks an implementer to assert something that cannot be asserted. It also
names a live assertion that must change:
conformance/test_review_baseline_admission.py:1546-1550 asserts
len(source_requests) == 1 and the exact Contents URL string. Restating P01's
observable as the selected component names and the ordered expected list would
close it.
P2 — name the provider fields, not their English descriptions. The contract says
"exactly one child with the exact component name", but the Git tree API returns
no name field; the field is path, and it is a basename only because the
recursive parameter is omitted — the very thing the contract forbids two sentences
earlier. Likewise mode is a JSON string ("040000", "100644"), and 040000
is not a writable integer literal in Python. Naming path and quoting the modes
removes both traps and makes the "omit recursive" requirement self-evidently
load-bearing rather than incidental.
P3 — v0.1 stays in the tree with no compatibility duty. This PR leaves both
versions under docs/rfcs/. Across 62 RFC files at this head, this is the only
duplicated document stem: every other version bump in the repository landed at its new
version with no predecessor ever committed (OFARM2_Proportional_Delivery_Workflow_RFC_v0_2.md,
OFARM_Native_Evidence_GitHub_CLI_Pin_Execution_RFC_v0_2.md,
…_Elapsed_Time_Correction_RFC_v0_3.md, …_Decision_Log_Evidence_Amendment_RFC_v0_2.md
were all added directly at v0_2/v0_3). EXC-004 asks for obsolete owned material to go
unless a time-bounded compatibility duty and deletion trigger are explicit; none is
stated. The counter-argument is real and I think it is close: the withdrawal banner
removes any ambiguity about which document is live, and EXC-004 enumerates code,
shims, flags and fallbacks, not documents. But v0.1 has never been merged, so
"preserved as history" is doing no work that commit f08cd7d and review B1 do not
already do permanently. If maintainers read EXC-004 as covering owned documents,
this becomes a Blocker; I have classified it as a Preference.
P4 — rewrap the late edits. v0.2 wraps prose at ~80 columns except four lines that
run 100–498 characters, all in passages edited after the v1 text was written. Cosmetic.
RFC claims I checked against the code and the live repository
| RFC claim | Result |
|---|---|
| Publisher recomputes artifact hashes under its own policy checkout | Confirmed — evidence_publication_policy.py:1128 hashes POLICY_ROOT / path |
| Producer hashes under the executed source root | Confirmed — run_review_baseline.py:786 hashes ROOT / path |
Refusal string review baseline verified artifacts differ |
Confirmed present at evidence_publication_policy.py:1132 |
| Source run 34149023176, attempt 1, passed | Confirmed — reviewed-head baseline gate, attempt 1, completed success |
| Publisher run 34151241570, attempt 1, refused, no receipt | Confirmed — evidence-publication, attempt 1, completed failure; the failing step is #14 "Rebuild authoritative conformance claims with trusted policy", i.e. stage-conformance. Job logs require authentication; I did not read the refusal string from the log |
Historical head 64d3cbd6… |
Confirmed — commit resolves, single parent 28235614 |
stage_conformance_evidence, _download_authenticated_source_file, _validate_baseline_evidence all exist and are the right seams |
Confirmed — reader has exactly one production call site (:1208, inventory) plus three in conformance/test_review_baseline_admission.py; the validator has exactly two call sites (:1228 producer runs, :1263 staged revalidation), both inside one function with source_commit already in scope |
| Existing 8 MiB limit and 30-second timeout | Confirmed — MAX_SOURCE_INPUT_BYTES = 8 * 1024 * 1024, timeout=30 |
| Publication workflow already supplies the execution commit | Confirmed — evidence-publication.yml:333 sets SOURCE_COMMIT from steps.publisher-start.outputs.execution_merge_sha |
| Three two-component paths → twelve reads | Confirmed by execution (see above) |
kernel/tests/test_postgresql_native_evidence.py already checks both pin relationships |
Confirmed — :4005-4090; and both pins are currently exact: policy file SHA-256 3ca8d543… equals OFARM_EVIDENCE_PUBLICATION_POLICY_SHA256, and evidence-publication.yml SHA-256 0e0f661e… equals the value pinned at conformance.yml:64 |
Current main is ff092c4… |
Confirmed live via git ls-remote |
| Both configured artifact files preserved (P06) | Confirmed — the diff is two files, both under docs/rfcs/ |
| Both v1 and v2 digests claimed in the PR comments | Both reproduce from fresh extraction |
| "The original RFC text remains unchanged below its withdrawal notice" | Confirmed — git diff f08cd7d..3d3b289 on v0.1 is +5/-0 |
| Probe ran on Python 3.12.13 | False as written — see Blocker 1 |
Checked and decided were not findings
- Fork-network object sharing does not undermine the commit read.
GET /git/commits/{sha}resolves objects across a fork network, so a 200 there is not by
itself proof of repository membership. It does not need to be:_bound_mergein
conformance/review_baseline_admission.py:336-370derivesexecution_merge_shafrom
the liverefs/pull/{n}/mergeref and refuses unless the merge commit's parents are
exactly[base_sha, reviewed_head_sha]. The execution commit is bound to this
repository's own PR merge and to the reviewed head before the reader ever sees it.
The RFC's delegation of that authority is sound. - The SHA-1 blob identity is not being asked to carry security weight. The RFC says
so itself ("verifies Git's existing object binding; it does not replace SHA-256
evidence hashes or create signing authority"), and the attacker in scope can already
put whatever bytes it likes in the file lawfully. A collision buys nothing. - The inventory does not acquire a second wrong-revision comparison.
_load_source_test_inventorypasses the fetched document to
run_review_baseline._inventory_document, which is a pure normaliser over the
entries it is given — it does not walkPOLICY_ROOT/kernel/tests. So growing
the test set (as #380 does, +682 lines of inventory) does not produce a second
refusal behind the one this RFC fixes. This was my main "is there another wall right
behind this one" hypothesis; it is wrong. - The 8 MiB ceiling has room. The inventory is the largest source input at
1,327,623 bytes / 4,269 entries — 15.8% of the limit. The artifacts are 6,798
and 2,199 bytes. The RFC is right not to raise the limit. truncatedwill not fire on the current paths. Non-recursive trees on the walk
are 41 (root), 21 (profile_si_ffs) and 17 (conformance) entries. GitHub truncates
around 100,000 entries or 7 MB; there is no realistic path to a truncation refusal
here, so refusing ontruncated is not Falsecosts nothing.- Refusing size 0 narrows nothing in practice. The contract's
1..MAXrange refuses
an empty regular file, but the existing reader already refuses empty payloads
("source input is empty"), so this is not new behaviour. - No cache is a defensible cost. With deduplication the 12 reads would be 7 (one
commit, one root tree, two subtrees, three blobs). All three paths share the commit
and root tree. The RFC forbids a cache; against a per-repoGITHUB_TOKENbudget,
five extra bounded reads per publication is not worth the state, and objects are
immutable so consistency is not at risk either way. - The URL-dispatching fixture the RFC asks for is achievable. The existing seam
(source_response_factory,test_review_baseline_admission.py:1531) returns one
payload for any URL; I built the dispatching version the RFC specifies and it works,
so that test requirement is not aspirational. - The enabling-PR rule is satisfied.
AGENTS.md:185-187forbids a separate PR that
merely enables another with no independently usable and testable outcome. This
correction is independently testable at the staging boundary and the PR body says so
explicitly. - The package contract check does not regress at this head.
conformance/ofarm_pkg_contract_check.pyon the CPython 3.12.13 I built returns
RESULT: FAIL (2 failures)— and returns the identical two failures at base
ff092c4:ModuleNotFoundError: No module named 'jsonschema'reached through
kernel/runtime_bundle.py:16, and "repository-pinned Ruff formatter is
unavailable". Both are missing tooling in my environment, not head defects; parse,
digest, instance-validation, temporal-candidate, temporal-decision-log and
architecture checks all executed and reported clean. I could not install the
lockedjsonschema==4.26.0: my interpreter has nosslmodule (no OpenSSL headers
on the build host) andbootstrap.pypa.iois not reachable from it. - Neither RFC file contains trailing whitespace or tabs.
What my method made easier than production
- My reference implementation is my reading of the RFC, not repository code. It
shows the contract is expressible, self-consistent and sufficient against 26 cases.
It proves nothing about the implementation that has not been written. A conforming
design can still be implemented wrongly, and the implementation review must repeat
these cases against the real reader. - Every provider response was fictional and locally dispatched. Field names,
shapes and modes came from GitHub's documentation, not from a live capture. If the
Git tree API's actual response differs from the documented shape in any respect the
design leans on —truncatedsemantics,sizepresence on blob entries, mode
spelling — my probes would not have noticed. A single live capture against a real
commit would retire this blind spot cheaply, and I would rather the implementation
PR carry one than not. - Neither probe crossed a network. Both went through the injected
response_factory, so the real opener,_HttpsOnlyRedirectHandler, TLS, GitHub's
actual status codes and any rate-limit behaviour were never exercised. - I ran no repository test suite, no PostgreSQL, no hosted baseline, no admission
and no publication. The only repository gate I ran is the package contract check,
and it did not complete cleanly for environmental reasons stated above. - My interpreter is
linux-aarch64; the pinned baseline isx86_64/
ubuntu-24.04. For a pure-Python probe this is very unlikely to matter, but it is
not the pinned platform, and I would rather say so than imply otherwise — which is,
after all, the subject of Blocker 1. - I could not read the publisher job log for run 34151241570; it needs
authentication. I confirmed the run failed and which step failed, not the refusal
string it printed.
Disposition
Fix Blocker 1 — a one-sentence correction, and the corrected evidence already exists
above if you want the stronger version of it. The version-2 supported-file contract
needs no design change on anything I could find: it closes B1, it survived every
hostile case I could construct against it, and its read-budget, custody and bootstrap
claims all reproduce.
After that correction, this Phase A looks ready for the same-task version-2 semantic
approval card, subject to the standing caveat that no review on this PR — including
this one — comes from an independent account.
No semantic approval, implementation acceptance, baseline admission, merge
authorization or publication bypass is supplied by this review.
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
PR #382 — scoped Phase A re-review, version 2
Verdict: B1 is resolved in the revised design. Zero new in-scope design blockers or follow-ups. Ready for the version-2 semantic-approval decision—not implementation acceptance or merge.
Reviewed head: 3d3b28924b19d813d36e9b5e663a2b89c0882f4d
Previous reviewed head: f08cd7d711617c5635cca2f8de1a9852f61976ec
Base: ff092c414db9fa24dbd6ab86c7722db89e0c95b5
The PR remains draft and design-only. This revision adds the 290-line version-2 RFC and a five-line withdrawal notice above the preserved version-1 text. Publisher code, tests, workflows and configured artifacts remain unchanged. This is a bounded re-review of B1, its repair and affected invariants, not a restarted audit.
Sources: version-2 design and revision delta.
1. B1 — Authenticated response versus supported file: resolved at design level
The revised contract establishes the missing chain:
Authenticated execution commit
→ matching root tree
→ exact selected path components
→ supported regular-file blob
→ matching byte count and Git blob identity
→ SHA-256 artifact expectation
Selected parent components must be trees with mode 040000; the terminal must be a blob with mode 100644 or 100755. Directory terminals, submodules and all symlinks on the selected path—including links to ordinary files—are explicitly refused. The reader must also reject missing or duplicate selected entries, truncated metadata and inconsistent object identifiers. This removes the ambiguity behind B1 rather than merely adding another response-body check.
The raw bytes must then match both the terminal's declared size and its Git blob identifier. The specified calculation correctly includes the blob <byte-length>\0 header; SHA-256 remains the separate evidence hash. GitHub documents raw-blob retrieval, and Git documents the object-ID construction.
The distinction is now object-based, not content-based. A real regular file containing JSON that resembles API metadata remains valid data. Conversely, matching producer hashes cannot turn a directory listing into a supported artifact. Applying the same strengthened reader to the inventory and both verified artifacts also avoids retaining an untyped secondary read path.
2. The provider contract and traversal bounds are executable
The proposed commit/tree/blob sequence matches the documented APIs. The commit response identifies its root tree; tree entries expose the name, mode, type and object identifier needed for component-by-component selection. These reads use the existing Contents: read permission class rather than requiring additional write authority.
The RFC correctly requires omitting recursive entirely. GitHub documents that supplying that parameter with any value—including "false"—enables recursion. This is a meaningful implementation detail, not cosmetic wording.
The revised request budget is coherent: a path with d components requires one commit request, d tree requests and one blob request. The three current two-component paths therefore require 12 bounded reads, replacing the withdrawn three-read assumption. The existing 8 MiB response limit and 30-second request timeout remain, with no recursive repository scan, cache or fallback.
I also inspected live commit and nonrecursive tree metadata at the reviewed head. The inventory, capability manifest and ActiveArtifactSet are each 100644 blobs beneath 040000 parents; their reported sizes are below the proposed limit. That supports compatibility with the current inputs, although it is not execution of the proposed reader.
Object metadata inspected: commit, root tree, conformance tree, and profile tree.
3. The verification plan now targets the actual counterexample
The strongest addition is the complete staging negative: both producer envelopes claim the same non-file metadata hash, their comparison is recomputed, and staging must refuse specifically at supported-file proof before authoritative output exists. That prevents an unrelated envelope inconsistency from concealing a missing file-kind check.
The planned controls cover the important distinctions:
| Verification area | Required distinction |
|---|---|
| Object proof | Directory, submodule, terminal-link and parent-link refusals; an inventory non-file case proves both consumers use the strengthened reader. |
| Content binding | Wrong object IDs, byte counts and blob hashes refuse independently of producer-list equality. |
| Legitimate content | Changed and unchanged regular files pass with matching hashes; executable-mode files and metadata-looking JSON remain inert data. |
The RFC also retains malformed/truncated metadata, boolean-size, transport-failure, response-URL substitution and exact request-sequence tests. These are implementation acceptance requirements already in the revised plan, not new scope from this review.
4. Scope, workflow pins and bootstrap remain controlled
The transitive pin dependency identified previously is now explicit:
evidence_publication_policy.py
→ policy hash in evidence-publication.yml
→ workflow hash in conformance.yml
Both updates belong to this same custody correction, with workflow behavior unchanged. The design still removes the old policy-root artifact calculation and supplies one required expected list to both producer validations and staged revalidation. No producer-selected path authority or alternate verification path is introduced.
The bootstrap remains separate from #380: preserve this prerequisite's configured artifact bytes and policy-owned baseline inputs so its own evidence can pass through the existing trusted default publisher. Candidate tests prove the new behavior; candidate publisher code must not substitute for trusted publication before merge. This preserves the existing evidence boundary without creating a dependency loop.
Verification and remaining limits
I independently checked the revised design, its delta from version 1, the relevant provider documentation, live repository object metadata and current-head lightweight job results. Workflow 34520864613 completed successfully, including publication/admission tests, lint, package/architecture and whitespace steps. I inspected job-step results, not a full baseline execution.
I did not run local repository tests, implement or execute the proposed reader, fetch and re-hash its raw blobs, or run hosted baseline/publication workflows. The reported 70 passing tests exercise the unchanged implementation and do not establish that version 2 works. The PR retains the initial environment failure and two existing extraction-consistency failures as disclosed evidence; this review does not waive any applicable gate.
Disposition
No further Phase A changes required from this review. Mark B1 resolved for the version-2 design at 3d3b28924b19d813d36e9b5e663a2b89c0882f4d, then proceed to the complete same-task decision card for OFARM2-SOURCE-ARTIFACT-PUBLICATION-001, version 2. Version 1 remains withdrawn, and implementation still requires the later valid approval.
This remains an implementation/conformance and repository evidence-policy RFC. No active OFARM baseline-law files need amendment. It does not yet resolve #380's publication hold; that depends on the implemented prerequisite and its own required verification and receipt.
This COMMENT supplies content-review findings only. It is not semantic approval, baseline admission, implementation acceptance, final quality acceptance, merge authorization or deployment authority.
|
Scoped evidence-attribution correction — PR #382 at Review 5172228902 identified ambiguous attribution in RFC v0.2. The paragraph is now explicit: original B1 used a copied reader on Python 3.13.5, outside the pinned interpreter, with fictional responses. It was supplemental probe evidence, not a live capture, end-to-end publication exploit or repository test run. Correction changes only that paragraph: 5 added / 3 removed lines. The earlier Python 3.12.13 sentence referred to a separate local reproduction, whose preserved record is reproduced below for provenance. It did not describe B1's probe. The corrected paragraph now attributes only the cited B1 evidence, so the two runs cannot be conflated. No historical test result or original review was rewritten. Retained local reproduction: unmodified imported
The preserved local JSON record has SHA-256 Bounded exact-head review: the AI reviewer Checks actually run: package contract PASS (0 failures), including architecture, before commit in the dedicated CPython 3.12.13 environment; whitespace PASS. No publication suite rerun was needed for this documentation-only correction. The earlier 70 passing tests remain historical checks of the unchanged implementation. The two existing extraction review-record failures remain disclosed; this correction changes no extraction inputs or applicability. No publisher implementation, database, admission, hosted baseline, publication rerun, merge or deployment was initiated. The policy-owned input follow-up and wording preferences remain non-blocking; no additional authority or cross-boundary change is appended. Scope remains evidence-publication custody, separate from PR #380. Its kernel changes remain untouched. Decision Next: obtain the later exact same-task version-2 approval, then implement the bounded correction and follow the existing verification and publication gates. |
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
PR #382 — scoped re-review of the attribution correction
Verdict: the evidence-attribution blocker is resolved. Zero new in-scope blockers or follow-ups. No further Phase A changes required.
Reviewed head: dc32be55e0a5908df46e76daf3ff50961b0b9c94
Previous reviewed head: 3d3b28924b19d813d36e9b5e663a2b89c0882f4d
Base: ff092c414db9fa24dbd6ab86c7722db89e0c95b5
The PR remains draft and design-only, awaiting version-2 semantic approval. This revision changes one paragraph in the version-2 RFC: five added lines and three removed lines. No implementation, test, workflow or artifact changes were introduced. See the exact revision comparison.
Evidence attribution: corrected
The RFC at the reviewed head now accurately describes B1's original evidence as an isolated copied-reader probe on Python 3.13.5, explicitly distinguishing it from the pinned Python 3.12.13 environment. It also states that the probe was supplemental evidence—not a live provider capture, end-to-end publication exploit or repository test run.
I checked that wording against the retained original probe results in the review conversation. The interpreter, copied-code method and three accepted synthetic metadata responses agree. The same limits are recorded in the original B1 review.
My previous version-2 re-review missed this attribution mismatch. The finding in review 5172228902 was valid. The current patch fixes it without substituting that reviewer's separate Python 3.12.13 imported-module reproduction for the original evidence. That separate reproduction remains separately reported evidence; I have not independently rerun it.
The version-2 design is unchanged
The exact commit comparison contains no changes to the supported-file contract, trusted path ownership, commit/tree/blob validation, selected-path symlink refusal, expected hash-list handling, workflow-pin dependencies or bootstrap conditions. The earlier resolution of the source-file-proof design blocker therefore stands. This is a reporting correction, not a semantic change requiring another decision version.
That remains a design-level conclusion. The shared reader and publication correction have not been implemented, and this paragraph edit does not resolve #380's publication hold.
Verification and limits
I confirmed that current-head lightweight workflow 34530118986 completed successfully and inspected its job-step results. The admission tests, publication-policy lint, package-validator tests, baseline-outcome tests, package/architecture check and whitespace check all report success. This is current-head lightweight evidence, not a full hosted baseline or publication receipt.
I did not rerun local tests, probes, the package checker or the extraction diagnostic. The PR continues to disclose the two historical extraction-consistency failures and distinguishes earlier test results from checks performed for this attribution-only edit. No applicable gate is waived by this review.
Disposition: mark the attribution finding resolved at dc32be55e0a5908df46e76daf3ff50961b0b9c94. The version-2 design is ready for the semantic-approval decision; implementation still requires valid same-task approval. No active OFARM baseline-law amendment is needed, and no implementation acceptance, baseline admission or merge authorization is given.
Submitted as COMMENT. This is content review through the connected account, not independent-account approval or task-user semantic approval.
Resolve trusted artifact paths through the authenticated execution commit and Git trees, accept only regular blobs, and verify content identity before hashing. Share one required artifact expectation across producer and staged validation. Add complete fictional staging and malformed-proof regressions, preserve policy-owned inputs, and refresh both workflow pins. Delivery #381; approved OFARM2-SOURCE-ARTIFACT-PUBLICATION-001 version 2.
|
Implementation content review — PR #382 at Zero Blockers, Follow-ups or Preferences in one divided implementation review pass. The existing shared reader proves exact execution commit → selected nonrecursive tree entries → regular blob → exact length/Git object identity. It refuses selected parent/terminal links, submodules, directory terminals, malformed/truncated metadata and substituted bytes. One bounded authenticated transport retains response limits and timeout; the source-only redirect handler refuses follow-up requests without changing archive handling. Fetched artifact bytes remain inert. Trusted configuration builds one ordered expected SHA-256 list, required by both producer validations and both staged revalidations. The obsolete policy-root artifact calculation and Contents read path are deleted. Complete fictional staging negatives use matching false metadata hashes in both envelopes and a recomputed comparison, then assert specific file-proof refusal and no output. Controls cover changed/unchanged artifacts, stale policy hashes, regular metadata-looking JSON and executable-mode inert bytes. Reader tests cover object identity, path depth, strict JSON, bounds and each transport stage. Both workflow edits contain only their required hash-pin replacement. All seven bootstrap inputs match base Confirmed SHA-256 values:
Executed local checks: 81 publication/admission methods passed in 21.702s; 1 existing pin/enforcement test passed in 0.15s; package contract PASS0 including architecture before commit; Ruff and whitespace PASS. Tests used fictional fixtures/temporary directories and no database. Native CPython3.12.13 tooling is supplemental, not locked Linux equivalence. The initial 1failure/14subtesterrors were fixture mistakes subsequently fixed; all logs retained. Extraction remains FAIL2 existing missing review records, disclosed with unchanged applicability. The reviewers inspected code/tests and identities without rerunning the already-passing tests or accessing a database. Same-task semantic approval for decision Next: create one fresh exact-head admission through the existing default-branch gate, then obtain required hosted/native/publication evidence and final receipt before the final task-user acceptance packet. |
|
Request fresh baseline admission for PR #382 after completed exact-head implementation review with zero Blockers. Same-task version-2 semantic approval is valid. Local publication/admission tests, pin enforcement, package and lint checks passed; existing extraction-record failures remain disclosed. Preserve all live admission, execution, publication and receipt gates. This technical trigger grants no merge or deployment authority. OFARM2_BASELINE_ADMISSION |
Use the existing offline generator after the approved publication hash pins are final. Only the conformance workflow digest and derived authority-input digest change; preserve the frozen receipt, release identity, native rules and tenant provisioning identity. This mechanical companion closes the preflight refusal observed in run 34571981032 for Delivery #381.
|
Bounded correction review at exact head The earlier source run34571981032, attempt1, refused at tenant migration preflight because the approved conformance workflow pin changed a whole-file input in existing verifier currentness. Both baselines and comparison were skipped. Both native jobs passed, but handoff was skipped; no receipt exists. The new head revokes the prior admission. No workflow attempt was rerun. The unchanged offline generator produced fresh temporary output; exact review confirmed only the conformance workflow SHA and resulting aggregate digest changed. Committed sidecar SHA-256: Existing targeted tests: 20 passed,198 deselected,0.26s; covers deterministic/no-clobber generation, wrong binding/stale/missing/unsafe record refusals, exact tenant identity and workflow-pin enforcement. Tenant preflight PASS, authenticating the unchanged11-migration set; no migration execution or database access. Package PASS0 before commit; whitespace PASS. Earlier81 publication methods and policy Ruff are unchanged implementation evidence. The two existing extraction review-record failures remain disclosed with unchanged applicability. Reviewer Next: fresh admission for this head, existing baselines/native/publication and receipt, then the final user packet. |
|
Fresh admission after zero-blocker review of the generated currentness companion. The prior source attempt's failure is preserved; this head supersedes its admission. This technical trigger supplies no merge or deployment authority. OFARM2_BASELINE_ADMISSION |
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
PR #382 — implementation re-review
Verdict: zero demonstrated in-scope blockers. Zero new follow-ups. No required code changes identified. Ready for final exact-head human acceptance—not automatic merge.
Reviewed head: 1b057a9af2658b9c985a3c3cc7bd86af6b83ef5c
Previously reviewed design head: dc32be55e0a5908df46e76daf3ff50961b0b9c94
Base: ff092c414db9fa24dbd6ab86c7722db89e0c95b5
The PR now contains the implementation, tests, workflow pins and generated currentness companion across eight changed files. It remains draft and unmerged. This is no longer the design-only state assessed previously. The head was checked again before posting and remains the reviewed SHA.
1. The source-file-proof blocker is resolved in the implementation
_download_authenticated_source_file() implements the approved chain: exact execution commit → matching root tree → uniquely selected path components → supported regular-file blob → matching byte count and Git blob identity. Parents require tree/040000; terminals require blob with string mode 100644 or 100755. Selected symlinks, submodules, directory terminals, ambiguous entries and truncated trees refuse before their content can become an artifact expectation.
The raw-byte binding is correctly separate from evidence hashing. The reader verifies the Git blob identifier using the blob <length>\0 header, then staging calculates SHA-256 over the returned bytes. It does not mistake metadata-looking content for a non-file: object kind comes from the selected tree entry. The chosen raw-blob media type and mode distinctions match GitHub's documented blob and tree interfaces.
The transport change is also appropriately bounded. A source-only redirect handler refuses before a follow-up request, while the archive redirect handler is unchanged. Authentication, exact final-URL checking, the 8 MiB response limit and 30-second timeout remain. No response-provided URL, checkout, source execution or fallback reader is introduced.
2. The wrong-revision comparison is removed without trusting producer claims
Staging obtains the paths from trusted configuration, constructs one ordered expected artifact-hash list, and supplies it as a required argument to both producer validations and both staged revalidations. The former POLICY_ROOT / path artifact calculation is deleted rather than retained as a fallback. Artifact retrieval and producer validation occur before authoritative output creation.
Configuration, dependency locks and schema remain policy-owned. Their existing checks are not silently converted into producer-selected expectations. The baseline documentation now states that distinction, and the tests preserve those refusal cases. This fixes the verified-artifact boundary—not every possible future change to verification-policy inputs.
3. The tests exercise the actual failure conditions
The strongest regression is present in the publication/admission test module: both producer envelopes contain the same false metadata hash, their comparison is recomputed, and the real staging function must refuse specifically at supported-file proof with no authoritative output. Directory, submodule, resolved-link, unresolved-link, parent-link and inventory-directory cases are covered. This avoids “passing” a negative test because an unrelated envelope field was invalid.
The complementary tests distinguish lawful changed-source bytes from stale policy hashes and invented other-revision hashes, including false claims in either run separately and in both runs together. They also test added, omitted, duplicated, changed and reordered artifact entries while checking that requests remain confined to trusted selections. Positive controls preserve executable-mode files and metadata-looking JSON as inert data.
The shared fixture is justified here: it supplies complete envelopes and exact-URL Git responses to existing staging consumers. It does not replace the validation decisions with mocks or introduce a general Git framework.
4. The generated currentness companion is acceptable
Both anticipated pin updates are present:
publisher policy
→ policy hash in evidence-publication.yml
→ publisher-workflow hash in conformance.yml
The workflow diffs contain the hash replacements, not changes to execution behavior or permissions.
Those bytes also affect the existing verifier-currentness manifest. I checked the additional sidecar diff: only the conformance-workflow hash and resulting aggregate digest change. Its schema, status, release-identity binding and frozen-receipt binding remain unchanged. The retained correction review records that the first source run correctly refused the stale sidecar rather than bypassing it.
The existing native-evidence RFC §9.4 expressly provides deterministic generation to a fresh temporary path, exact review and replacement through an ordinary repository diff. On this patch, the sidecar is a required mechanical companion—not a new provisioning identity, receipt rewrite or currentness-policy redesign.
5. The publication hold is cleared for this prerequisite
I inspected the current-head lightweight execution log and downloaded the final receipt and published baseline archives. The evidence now goes beyond PR-description claims:
| Evidence examined | Result |
|---|---|
| Current-head publication/admission unittest execution | 81 tests passed; overall result OK |
| Lightweight package/architecture, lint and whitespace checks | PASS |
| Both published baseline result sets | 4,269 passed each, one warning each; no failures, skips, deselections or unavailable tests |
| Baseline report integrity | Result-file bindings and both raw envelope hashes match |
| Clean-run comparison | Reports equivalent; independent comparison found equality outside the declared volatile fields |
| Native verification | Both architecture jobs report success; publisher reauthentication steps report success |
| Final publication | Receipt issued successfully by the existing trusted default publisher |
Publisher run 34575188363 completed authoritative staging, native reauthentication, final admission checks and receipt upload—not merely provisional artifact creation.
I independently confirmed that:
- The receipt ZIP and baseline ZIP digests match live GitHub artifact metadata.
- All four source and five published artifact references in the receipt match the retrieved metadata.
- The receipt identifies this head, admission comment
5630765525, and execution merge100eeeb051c149c5d032942e3c6b7bc59bbd3afa. - That merge commit has exactly the stated base and reviewed head as parents.
The supplemental offline evidence-check record is retained in the review conversation as implementation_evidence_check.json; it is not a repository artifact or an additional authoritative publication receipt.
The bootstrap distinction remains important: publisher run 34575188363 used existing default policy ff092c414db9fa24dbd6ab86c7722db89e0c95b5. The new reader's changed-source behavior is exercised by the candidate tests; this receipt does not demonstrate the new reader operating as the trusted production publisher. That is the intended pre-merge sequence, not an evidence substitution.
Limits and disposition
I did not execute repository tests locally, independently reauthenticate the native binary archives, rerun the sidecar generator, or retrieve the original task-user approval messages. A local clone attempt failed because the container could not resolve GitHub; source review continued through the connected GitHub tools. The offline work here checked downloaded evidence bytes and internal consistency, not runtime behavior.
The two disclosed extraction-consistency failures remain failures, and policy-owned configuration/lock/schema revision handling remains a separate follow-up. Neither is silently closed or waived by this review.
Recommendation: proceed to the final exact-head acceptance packet without further implementation changes. This remains an implementation/conformance and repository evidence-policy correction; no active OFARM baseline-law amendment is needed. After authorized merge, PR #380 still requires its own fresh applicable verification and publication—it does not inherit this PR's receipt.
Submitted as COMMENT. This is content review through the connected account, not independent-account approval, task-user final acceptance, a baseline-admission trigger or merge authorization.
1 participant
Outcome and Delivery
Closes #381; Tracking Epic #167. This separate prerequisite for #379 / PR #380 implements one evidence-publication custody correction. The trusted publisher now compares verified-artifact claims with proven file bytes at the authenticated execution commit. Correct changed-source hashes pass; stale or fabricated claims refuse. PR #380's kernel changes remain separate.
Current implementation head:
1b057a9af2658b9c985a3c3cc7bd86af6b83ef5c. Reviewed Phase A v0.2 records the contract, threat model and verification plan. The PR remains draft and unmerged. Exact-head review, local and hosted checks, trusted publication and the final receipt have passed. Final task-user acceptance and later exact-head merge authorization remain required.Approval, authority and scope
Decision OFARM2-SOURCE-ARTIFACT-PUBLICATION-001 version 2 received the entire exact user approval in the same Codex task on 2026-09-11. The original complete card (
msg_0d813f8071772f9a016aa306cc501887d29bc6376ae2502097) and later user message (msg_01a08f35-cbed-7060-8fe7-31a47249fdb6) were directly retrieved in order from task01a07cc8-4157-7b33-a0ca-becb772e0e8b. This paragraph is navigation only; the original task-user message owns authority. Version 1 remains withdrawn. The attribution-only correction required no semantic version change.The user retains final quality acceptance and later exact-head merge authority. Trusted default configuration chooses paths and policy inputs; the existing admission/source/ticket chain chooses repository and execution coordinates; authenticated GitHub metadata proves selected object kind; trusted publisher policy checks evidence; final receipts establish publication custody. Producer evidence and source bytes remain untrusted. Compromise of trusted policy, publisher credentials or GitHub/TLS is outside this bounded threat model. The main risk is a producer presenting self-consistent false hashes or non-file metadata as artifact bytes; independent file proof and exact comparisons contain it.
Scope stayed within evidence-publication custody. No kernel semantics, credentials, database roles/transactions, runtime activation, capability/provisioning manifests, ActiveArtifactSet, canonical/contracts, deployment or release changes. The existing verifier-currentness sidecar is mechanically refreshed as described below; its schema, status, receipt/identity links and validation rules are unchanged. No cross-boundary exception, source checkout/execution, historical evidence rewrite, workflow-attempt rerun or receipt bypass.
Implementation and invariants
100644/100755. Parents requiretree/040000. Selected links, submodules and directory terminals refuse, as do malformed/truncated metadata and mismatching identities, sizes or blob hashes.ff092c414db9fa24dbd6ab86c7722db89e0c95b5. This prerequisite must obtain its own receipt from existing trusted default policy before merge; candidate tests cannot substitute for that publisher.Both mechanical pins are refreshed: publisher policy →
evidence-publication.yml→conformance.yml. Workflow behavior and permissions are unchanged. The complete staging fixture is shared by success and refusal cases; its Git responses dispatch only on exact URLs. Matching false metadata hashes in both envelopes with recomputed comparison still refuse specifically at file proof before output. Tests also cover stale policy hashes against changed source, different source hashes, executable-mode and metadata-looking regular files, preserved policy inputs, raw-byte substitution and transport failures.The first admitted source run 34571981032, attempt 1, refused at tenant migration preflight:
checked tenant native-verifier authority is invalid or stale. Both baselines and comparison were skipped; both native architecture jobs passed, but handoff was skipped and no receipt exists. The failure is preserved and the new head revokes its admission; no attempt was rerun.The conformance workflow is a whole-file input to the existing currentness manifest. Following the accepted native CLI RFC v0.2 §9.4, the unchanged offline generator produced fresh temporary output, which was exactly reviewed before checked-file replacement. Only the workflow SHA-256 and resulting aggregate digest changed (sidecar SHA-256
c147c2706c13ca468b16ae472ad5a997d1b32ec976cad8b5e9b8db7c859eef13). All other fields and bytes, all native rules, the frozen receipt and release identity remain unchanged. This satisfies the existing currentness check for the already-reviewed pin bytes; it introduces no independent authority decision or capability. Under AGENTS.md's generated-evidence discovery rule, it is an additional mechanical companion within the approved boundary, requiring no new decision version. The existing provisioning identity test confirms unchanged tenant manifest bytes/digest.Code excellence and changed areas
The implementation changes six paths: publisher policy, existing conformance unittest file, baseline documentation, two workflow pins and the existing generated verifier-currentness sidecar. Design history adds the two RFC paths to the complete PR. No kernel root test changed, so no root inventory regeneration is indicated.
EXC-001/002: one source reader and expected list, no duplicate authority or persistent cache. EXC-003: P01-P06 trace to complete staging/reader tests, preserved-input comparison and existing pin enforcement. EXC-004: remove the old Contents source path and local artifact-hash calculation. EXC-005: one bounded transport helper serves commit/tree/blob reads; its small source-only redirect handler enforces the approved no-follow rule without altering archive handling. EXC-006: a selected component walk proves parent-link refusal without checkout, a recursive repository scan or a generic resolver. No new registry, signing authority or durable state. Preferences remain non-blocking.
Executed checks and honest limits
Local CPython 3.12.13 on Darwin ARM64, dedicated task environment, fictional fixtures and temporary directories. The 49 baseline dependency versions and checker version are repository-pinned; native wheel identities are recorded separately and are not locked Linux baseline equivalence. All database DSNs used for the pin check were explicitly invalid; no database was created or accessed.
test_evidence_publication_policy_is_transitively_authenticated: 1 passed in 0.15 seconds, checking both hashes and workflow enforcement.conformance/review_baseline_test_inventory.jsonandkernel/tests/test_rewrite_architecture_check.py. The checker and extraction records are unchanged; execution/reporting does not waive any applicable gate.The complete version-2 design review and narrow attribution repair were reviewed to zero Blockers before user approval. Prior review 5172228902, review 5172232108, and attribution disposition are design/history, not acceptance of this implementation. Agent-assisted content reviews through the PR-author account do not supply independent-account approval or task-user intent.
Hosted and published evidence
Fresh admission5630765525 remains unedited. Source 34572760216, attempt1, passed: 4,269 tests per baseline, clean-run equivalence, 23 platform checks, both native architectures and sealed handoff. The exact expected Starlette warning inventory matched; no baseline skips, failures or deselections occurred. Hosted CPython3.12.13 / Linux x86_64 / PostgreSQL17.10 used three distinct isolated server identities. Current-head lightweight34572641519 also passed.
Trusted publisher 34575188363, attempt1, passed under existing default policy
ff092c414db9fa24dbd6ab86c7722db89e0c95b5. Final receipt10189355421 archive SHA-256 is98798e236cdde712772da57066627cf81a5fa5931018dae388139a0b73d02de3. Its downloaded bytes match that digest; all four source and five published artifact references match live metadata. It binds this head, execution merge100eeeb051c149c5d032942e3c6b7bc59bbd3afa, source/publisher attempts and the live unedited admission. The downloaded published baseline archive also matches its digest; both report hashes, test summaries and equivalence agree. Native bytes were reauthenticated by the trusted publisher; no downloaded content was executed locally.Final scope/excellence recheck: eight paths,1,461 additions/234 deletions; no independent capability or boundary added. Both worktrees are clean. No new review or revocation arrived during verification. Historical policy-owned config/lock/schema revision handling remains a separate follow-up; no new scoped Follow-ups or Preferences. Preserved local extraction diagnostics do not waive any applicable requirement.
Remaining human acceptance
All required scoped technical and publication gates have passed. The final packet must be presented in the same Codex task and followed by a later exact-head user authorization before merge. No merge or deployment authority exists. All work remains provisional repository development; deployment requires independently human-controlled approval. Changed capability, authorities, invariants, supported-file policy, named PR or production posture requires a new decision.
PR #380 stays draft at
d71c1d4cc304a50efc3983a77906f74686ff0946and needs its own fresh applicable verification after this prerequisite is merged with user authorization. No workflow attempt was rerun and no candidate publisher was substituted for trusted policy.Next: final task-user acceptance and later exact-head authorization for PR #382, then its normal merge rechecks.