Skip to content

security(attestation): authenticate scientific validation evidence across repositories #2299

Open

Description

@seonghobae

Owner-boundary finding

ContextualWisdomLab/TEPP#488 now binds ScientificallySupported recovery authority to exact grouped recovery payload identity, ordered seed-manifest membership, per-replication seed/execution/payload receipts, exact-head test receipt identity, and represented pre-execution profile chronology (#623–#636). The remaining production-integrity boundary is outside TEPP's scientific owner: the exact-head artifact/status, execution-artifact identities, and owner-ledger entry identities are still trusted-adapter inputs.

TEPP must not solve this by embedding a repository-local signing key, copying GitHub/OIDC logic, or calling a mutable sibling source. The organization control plane owns reusable cross-repository attestation. Existing .github#783 / exact-artifact-sbom-attestation.yml establishes sealed-artifact signing discipline; #2164 repairs reusable-workflow source identity with OIDC job_workflow_ref + job_workflow_sha; #2166 applies that pattern to product-performance evidence. Scientific validation needs a separate versioned predicate/contract rather than overloading the SBOM or product-performance predicates.

Required owner contract

Provide an organization-owned reusable scientific-validation evidence attestation workflow and verifier, invoked only by immutable full commit SHA after the reusable-workflow identity prerequisite in #2164 is protected authority.

At minimum the sealed inert evidence set and predicate must bind:

  • caller repository and exact candidate Git SHA;
  • workflow/run identity and same-run immutable artifact ID, name, size/digest metadata;
  • scientific profile SHA-256 and profile-chronology SHA-256;
  • exact-head test receipt binding identity plus the underlying exact-head test artifact identity/status;
  • canonical ordered seed-manifest SHA-256;
  • grouped recovery_evidence_sha256;
  • ordered replication_provenance_sha256 and the per-replication execution-artifact identities needed to verify that aggregate;
  • a versioned predicate type, for example https://contextualwisdomlab.org/attestations/scientific-validation/v1.

The uncredentialed intake/verifier must re-read authenticated live repository/run/artifact metadata, download by immutable artifact ID, enforce bounded regular-file/cardinality/path rules, parse evidence strictly as inert data, and independently re-hash all declared identities. Caller/product code must never execute in a job holding id-token: write, attestations: write, or artifact-metadata signing authority.

The credentialed signer must independently resolve the called reusable-workflow source from GitHub OIDC claims, use an immutable reviewed actions/attest pin, and attest only the sealed verified subject/predicate. The resulting bundle must then be verified against exact caller repository/source SHA, central signer repository/workflow identity, expected predicate type, subject digest, GitHub OIDC issuer, and any repository-owner policy needed by the consumer. Retain a Sigstore bundle/trusted-root or equivalent offline-verification artifact where the underlying owner contract supports it.

Scientific boundary

This attestation authenticates origin/integrity/provenance of scientific evidence; it does not decide RMSE, bias, coverage, convergence, estimator validity, design adequacy, construct validity, or ScientificallySupported numerical acceptance. TEPP Validation Evidence remains the owner of those semantics. The signer must not recompute or replace psychometric arithmetic and an attestation must never convert failed/queued/skipped scientific evidence into success.

Likewise, a signature alone does not prove that a declared RNG state caused an execution unless the sealed evidence/predicate explicitly binds that execution artifact to the represented seed/profile/run identity. The verifier therefore needs negative contracts for substituted execution artifacts, profile chronology, seed manifest, grouped payload, or exact-head receipts even when every supplied SHA is syntactically valid.

RED / acceptance

Before GREEN, add deterministic owner-level RED fixtures for at least: wrong caller repository; predecessor/wrong source SHA; wrong reusable-workflow identity; mutable ref; wrong run/artifact ID or digest; replaced evidence bytes plus replaced caller digest; malformed or extra files; symlink/path traversal; wrong predicate; profile/chronology mismatch; exact-head receipt mismatch; reordered/substituted replication provenance; wrong execution artifact; invalid/missing signature/bundle; and unexpected signer/issuer.

Acceptance requires normal protected review and exact-head quality/security evidence for the reusable owner contract, then an unchanged-head cross-repository canary that signs and independently verifies one inert scientific-validation evidence bundle. Publish/version the contract so TEPP consumes a released or exact immutable owner artifact; do not make a mutable owner branch a production dependency.

Prerequisites / integration

Refs ContextualWisdomLab/TEPP#488 ContextualWisdomLab/TEPP#636 #783 #1228 #2164 #2166.

Activity

  1. seonghobae commented on Sep 20, 2026

    @seonghobae
    ContributorAuthor

    Owner-path implementation has started in PR #2300 without claiming the credentialed signer prematurely.

    Current lineage:

    • source-level RED 2616480d4af805d28ff4b2c0ff257b005a52d3f4;
    • inert sealed-evidence verifier 6a29685a680b23d8b3af0b684769cfcacdd0d64e;
    • hostile-fixture repair e13885ce7bba9c5400f9fbb6277d47b556718404;
    • exact-head terminal-state predicate binding 9f01e4e7b3700a43085b0475c32fd1f5a986e844;
    • doctoring/CHANGELOG c25f917e8aaa567dd17216ab090f50c9320ecbcd;
    • exact-head verifier quality workflow 1359339713704e57a0a229ee213a409aa3641be8 requiring 100% owned line/branch and docstring coverage.

    #2300 is Ready because the verifier foundation is independently mergeable, but it explicitly does not close #2299. It contains no id-token: write, signing key, actions/attest, or copied TEPP scientific arithmetic. The credentialed reusable signer remains gated on #2164/#2133 as documented.

    #2164 RCA is now narrower: its Python CodeQL finding is inherited from its 233-commit-stale base and already repaired on current protected .github/main; its Actions SARIF is clean but the GHAS base/head identity probe receives 403, which remains #2133 owner work. Therefore the signer prerequisite should reconcile #2164 ordinary-forward and repair #2133 if the 403 persists, not weaken #2300 or copy mutable code.

  2. seonghobae commented on Sep 20, 2026

    @seonghobae
    ContributorAuthor

    Owner-path update (fresh live reconciliation): reusable-workflow identity prerequisite #2164 has been ordinary-forward reconciled with protected main@e6334e229581a918e2f22de18733b76fa65d7e71 at exact head a20726c1c4a387bba30e5609d550e36d2b0b3087 using a two-parent non-force merge. Its exact-head security/review workflows are newly generated and still non-terminal, and there is no qualifying current-head approval, so this is not a landing/release claim yet. Closed #2133 is no longer a live blocker.

    The product-performance sibling #2166 was separately non-force restacked onto #2164 at 43aa19ac0518982aae56d9fd3f1978a6b9e87c78; fresh compare is ahead 52 / behind 0 with merge base exactly a20726c1... and an 11-file product-performance-only residual. Keep that predicate/schema isolated from this scientific-validation contract.

    #2300 remains the correct scientific verifier lane. Do not add signer authority or ask TEPP #637 to consume a mutable owner branch until #2164 normally lands and this owner contract has exact-head GREEN/review plus an immutable/pinned consumable authority.

  3. seonghobae commented on Sep 20, 2026

    @seonghobae
    ContributorAuthor

    Verifier-foundation update: #2300 advanced to exact 9e82de292772111dc4b4afa178150b9e10fe6cb4 with #2301 output-authority hardening. The unsigned verifier now rejects symlinked/non-directory output ancestry, predicate/manifest destination collision, and outputs inside the sealed evidence root before publication. RED lineage is 2205025... + quality inclusion 41fbde2...; causal repair is c2cc2c1...; current doctoring/head is 9e82de2....

    This does not satisfy #2299 signer acceptance. Current exact-head quality/security jobs remain non-terminal with no assigned runner on verifier-quality, and there is no submitted independent review. #2164 also remains Draft/unlanded. Keep credentialed signer/cross-repository canary work behind normal #2164 landing/pinned identity authority; do not treat #2300's mutable branch or hashes as authenticated evidence.

  4. seonghobae commented on Sep 20, 2026

    @seonghobae
    ContributorAuthor

    Owner-path update from #2300/#2304: exact verifier head is now 787d9a4f4f27eb5d81bb2cbb94d9e4a0a162cd07 on feat/scientific-validation-attestation-2299, ordinary-forward from protected main@e6334e22... (ahead 26 / behind 0).

    #2304 repaired the remaining sealed-root ancestor TOCTOU: root authority is pinned through a component-wise O_DIRECTORY | O_NOFOLLOW descriptor walk, one-member enumeration is descriptor-based, and the leaf is opened relative to the same root descriptor. Lineage: RED 50edf085... → repair 85e2c07e... → coverage 7398c85c... → current doctoring 787d9a4f....

    Do not consume this mutable branch as signer authority. The next owner step remains #2164 exact-head acceptance/normal protected landing, then credentialed signer + independent live artifact metadata + OIDC source identity + immutable actions/attest pin + online/offline verification. Current #2300 checks are newly queued/non-terminal and no hosted GREEN is claimed.

  5. seonghobae commented on Sep 20, 2026

    @seonghobae
    ContributorAuthor

    Verifier-foundation update from #2300/#2305: output publication now has the same descriptor-pinned authority discipline as sealed evidence intake. Source RED e56ab5735be195ce7b9016b7a69713521621170d demonstrates that validating an output parent and later reopening its pathname allows rename+symlink redirection. Repair d0e00074ef2a3ab52ba1bf2069143baec9116f3b pins each output parent descriptor before evidence verification and creates/replaces predicate/manifest files relative to that descriptor; d755e8f9... covers descriptor-relative cleanup, and 076fff5e... removes the remaining path-based compatibility writer. Current #2300 head is ec476c871ee524b6577375e4ed89be54911a4fd5, ordinary-forward ahead 32 / behind 0 from protected main@e6334e22....

    This does not satisfy #2299 authentication acceptance by itself. Current #2300 remains an unsigned inert-data verifier; exact-head quality/security runs are non-terminal, and #2164 remains Draft/unlanded. The next authenticated step remains protected #2164 landing, then separate uncredentialed live-metadata intake + credentialed OIDC signer + reviewed immutable actions/attest pin + cross-repository canary + online/offline verification. No TEPP consumer should depend on the mutable #2300 branch.

  6. seonghobae commented on Sep 20, 2026

    @seonghobae
    ContributorAuthor

    Verifier-owner status update: PR #2300 is now exact eb86a8d1688d79d43dfa901f6d88b3aab94644d1, including #2306 stale-output no-clobber handling and code-current docs. Its new quality/security generation is non-terminal. The prerequisite #2164 remains exact a20726c1c4a387bba30e5609d550e36d2b0b3087, Draft, with non-terminal exact-head jobs. Keep #2299 open: the current verifier branch is not yet protected/pinned authority and TEPP #637 must not consume it as such.

  7. seonghobae commented on Sep 20, 2026

    @seonghobae
    ContributorAuthor

    Owner-path update from PR #2300 current exact head 5ef30e11082b4540517ea0a068662595ac0f1070 (ordinary-forward vs protected main@e6334e229581a918e2f22de18733b76fa65d7e71, ahead 48 / behind 0).

    Two additional verifier-boundary findings were repaired without moving scientific meaning out of TEPP:

    Signer implication: future credentialed signing must require successful verifier exit plus the final manifest, independently hash the exact predicate bytes, require equality with manifest predicate_sha256, and only then proceed to OIDC/source-identity and immutable actions/attest verification. #2300 remains unsigned local-integrity foundation; this is not yet authenticated provenance authority.

    Current exact-head workflow generation: Scientific Validation Evidence Quality 35537479913, Semgrep 35537479922, CodeQL PR 35537479963, Python Security 35537480048, Security Scan 35537479970; all queued. verifier-quality job 106148981734 has runner_id=null, no runner name, steps=[]. No hosted GREEN or qualifying independent APPROVED review is claimed.

  8. seonghobae commented on Sep 20, 2026

    @seonghobae
    ContributorAuthor

    Owner-path update from #2300: #2309 now gives the unsigned verifier completion marker an independent major-versioned manifest contract (.../scientific-validation-manifest/v1, schema 1.0) and reusable strict validate_receipt_manifest that re-hashes exact predicate bytes before signer consumption. #2310 then repaired the current review finding where filename-derived temporary inode names could exceed NAME_MAX; RED 52af99aa... → causal repair bbd66340.... Current canonical verifier head is 8ac4fd80bf9f823f32e59ab4bcd4f644c2c851dc, ordinary-forward from protected .github/main@e6334e22... (ahead 57 / behind 0; merge base exact main), Ready/open/mergeable. This remains unsigned mutable owner source: signer/OIDC work must still wait for #2164 protected landing and current-head #2300 gates/review, then independently validate the manifest+predicate bytes before credentialed attestation. Do not treat #2309's versioned marker as provenance authenticity by itself.

  9. seonghobae commented on Sep 20, 2026

    @seonghobae
    ContributorAuthor

    Further verifier-owner hardening on #2300: #2311 closes a semantic split left after #2309. predicate_sha256 already committed exact predicate bytes, but duplicated manifest policy fields were syntax-only and could contradict those bytes. RED 924fcf99... → repair b8b3cb1d... + coverage 05f0d4f4... now strictly parse the exact predicate, preserve origin_and_integrity_only plus the full does_not_prove boundary, and cross-bind repository/SHA/run, predicate type, artifact metadata, evidence filename/SHA, and ordered execution identities. Current doctoring is a78873c6.... This is still unsigned mutable owner source; #2164 protected landing and current-head #2300 gates/review remain prerequisites before credentialed signing.

  10. seonghobae commented on Sep 20, 2026

    @seonghobae
    ContributorAuthor

    Owner-path update: fresh review of #2300 found a deterministic current-head test-contract regression after #2310. The cleanup test still expected the removed .out.json.* temporary namespace, so a runner would fail inside the mock before reaching the intended typed hard-link publication error and could miss a real .scientific-validation-*.tmp leak. Tracked as #2312 and minimally repaired in d62649880e298a425bcef94b4375ce21194b2600; CHANGELOG 129e6c8f... and doctoring/current head 6b956ca43f54d716f66164d0d63e4383edf7b75f are current. Production publication semantics were not weakened. Base→head is ahead 65 / behind 0 from protected main@e6334e22.... Current exact-head checks have materialized as 17 queued checks; no hosted GREEN or independent APPROVED review is claimed. #2164 remains the prerequisite before any credentialed signer/OIDC authority can consume this verifier.

  11. seonghobae commented on Sep 20, 2026

    @seonghobae
    ContributorAuthor

    Owner-path update: PR #2300 is now exact d4a68892bfddfc5b9623eee8a3136b188eeaf530 (protected main@e6334e229581a918e2f22de18733b76fa65d7e71, ordinary-forward ahead 70 / behind 0). New #2313 closes a verifier/signer-parser fail-closed gap: byte-bounded over-limit integer conversion and excessive JSON nesting no longer escape the typed evidence contract as raw ValueError / RecursionError. RED 71801e8... → causal repair 14159dde... → realistic nesting-fixture correction ef73ac2...; CHANGELOG/doctoring are current at d4a68892....

    This does not create signer/OIDC authority. Current exact-head quality/security generation is still queued with no runner assigned to verifier-quality, so hosted GREEN is not claimed. #2164 remains the prerequisite for authenticated reusable-workflow identity. Keep the next phase as uncredentialed live metadata/artifact intake → independent credentialed signer re-verification → immutable reviewed attestation workflow → cross-repository online/offline verification.

  12. seonghobae commented on Sep 21, 2026

    @seonghobae
    ContributorAuthor

    #2314 owner-path progression is now implemented on canonical verifier PR #2300 exact 73d64a726d31acee8fba200220640702b53f8608.

    Fresh review against #2299 found that the unsigned predicate/manifest bound live artifact ID/name/digest but omitted the required GitHub artifact size_in_bytes metadata. #2314 adds a source-level RED (2a8d86c4895419d24389dd36da051bed9fd0bae8) and quality inclusion (47ac935c2e92196971048322de84b4b23b1af288), then production repair a0c75c0eeb4bae31fd1dbeece902d90354901b3c requires positive-decimal --evidence-artifact-size-in-bytes, commits it in both predicate and completion manifest, and cross-binds those values in validate_receipt_manifest. It is explicitly not inferred from the extracted evidence JSON length.

    Current exact generation for 73d64a72... is still non-terminal: Scientific Validation Evidence Quality 35547033557, SAST 35547033588, Python Security 35547033549, CodeQL 35547033502, Security 35547033471 are queued; verifier-quality job 106174679986 has no runner and no steps. No hosted GREEN or signer authority is claimed.

    #2164 remains the prerequisite for OIDC reusable-workflow identity. After it lands normally, the #2299 workflow must still re-read live artifact ID/name/size/digest + repository/head/run independently and have the credentialed signer repeat that verification before attestation.

  13. seonghobae commented on Sep 21, 2026

    @seonghobae
    ContributorAuthor

    Owner-path update from #2315 / #2300: exact head is now 18123738410ea5c3bbec1103e5ddaa2606f54b2d (ordinary fast-forward from 73d64a72..., protected-main merge base unchanged).

    The unsigned foundation now has a separate signer-facing bounded receipt-file intake before validate_receipt_manifest(): 4 MiB per manifest/predicate file, descriptor-pinned unsymlinked parents, one-shot O_NOFOLLOW | O_NONBLOCK leaf read, regular-inode check, distinct receipt paths, and exact-byte semantic delegation. This closes the availability/file-authority gap where a future credentialed signer could otherwise read/hash arbitrarily large or hostile receipt files before semantic refusal.

    This does not authenticate the signer path. #2164 must still land normally before the reusable-workflow OIDC source identity is protected authority, and #2299 still needs live GitHub run/artifact re-resolution, credentialed signer isolation, immutable reviewed actions/attest, cross-repository canary, and online/offline bundle verification. Current #2300 exact-head gates are non-terminal; no GREEN or release claim.

  14. seonghobae commented on Sep 21, 2026

    @seonghobae
    ContributorAuthor

    Owner-foundation progression: #2300 is now exact c9bff9731bce5c795238c4ca4713a448bc4512f1 after #2320. #2320 adds the missing crash-durability boundary for the unsigned receipt writer: RED 047d1d90b6db82231c91625c9dd81f28e1debba0 requires final directory-entry fsync and typed failure; repair 0982584de36114b5bf38149276ecbf4e6680f42e fsyncs the already-pinned output-parent descriptor after each successful no-clobber hard link. CHANGELOG 7361f8e98418202b2b67b6f8501b0f1164b59924; doctoring/current head c9bff973.... Current exact-head checks remain queued, so this does not satisfy #2299 acceptance or create authenticated signer authority. #2164 must still land normally first, followed by live metadata re-resolution, credentialed signer, immutable reviewed attestation action, cross-repository canary, and online/offline bundle verification.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions