open/llm-ingestion-okf
1
0
Fork 0
Code Issues Pull requests Releases Activity

docs(okf-v0.2): V6 -- Door C imports the pointer, never the code it points at

Browse source 
Measured, after asserting the opposite to the security repo an hour earlier: no
door in this library can create, import, or persist an executable file. Door C
skips every suffix that is not .md (importer.py:226-231); Door B has no extractor
for .py in either the core or the optional set (extract.py:113,131-142); Door A
writes only ingest-*.md. We told the guard a third-party attester .py could reach
a consumer's tree through our door. It cannot. Reasoned, not measured, corrected
the same hour.

The real exposure is the inverse. Door C writes a merged concept verbatim,
frontmatter included, and under v0.2 that frontmatter can carry
executor.resource and attester.resource. So we import the reference to executable
code while never importing the code. Either the pointer dangles -- noisy, safe --
or it resolves to something else already in, or later added to, the destination
tree, and the imported concept references code it never shipped. That second one
is a substituted reference, not a broken one, and it looks valid.

Also recorded: the guard is a PERSIST gate, and executable code carries its risk
at EXECUTION. A .py entirely safe to store may be dangerous to run, so no persist
gate covers the class section 10 introduces, and the execution boundary has no
owner in this stack -- upstream deferred the attester ABI and sandboxing, and we
declared runtime out of scope on that same deferral. Written down because "the
guard covers it" is a reasonable conclusion to draw and a hard one to catch later.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01A2aKJxLejT9S8jYwoZ9fut
This commit is contained in:
Kjell Tore Guttormsen 2026-07-26 19:41:20 +02:00
commit bec5608106
1 changed files with 46 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

46
docs/plan/okf-v0.2-alignment.md
View file

@ -819,6 +819,52 @@ version, and the root-frontmatter policy expresses any value.
**V5 — Attestation scope.** Answered by D4: format in, runtime out, on upstream's
own deferral rather than our preference.
**V6 — Door C imports the pointer but never the code it points at.** Raised with
`llm-ingestion-pipeline-security`; the decision is theirs.
Measured 2026-07-26, in our own code: **no door can create, import, or persist an
executable file.** Door C walks `rglob("*")` and skips every suffix that is not
`.md` (`importer.py:226-231`, an explicit case-folded test rather than a `*.md`
glob, since glob case-sensitivity follows the filesystem). Door B resolves an
extractor by suffix and `.py` is in neither the core set (`md`/`txt`/`csv`/`json`/
`html`) nor `_OPTIONAL_EXTENSIONS` (`pdf`/`docx`/`xlsx`), so it fails fast
(`extract.py:113,131-142`). Door A writes only `ingest-*.md`.
That is a stronger posture than we first told the guard — and we told them wrongly,
asserting that a third-party attester `.py` could reach a consumer's tree through
our door. It cannot. The claim was reasoned, not measured, and it was corrected the
same hour.
**The real exposure is the inverse, and it is ours before it is theirs.** Door C
writes a merged concept **verbatim**, frontmatter included. Under v0.2 that
frontmatter may carry `executor.resource` and `attester.resource`. So we import the
*reference* to executable code while never importing the code. Two outcomes:
1. The pointer dangles. A consumer following it fails — noisy, safe.
2. **The pointer resolves to something else.** The path is relative to the bundle
root, so if the destination tree already holds — or later gains — a file at
`attesters/sql_equality.py`, the imported concept now references code it never
shipped. Not a broken reference: a substituted one, and it looks valid.
Outcome 2 is the one worth attention. We have not measured collision likelihood;
the reference bundle's path names (`attesters/`, `skills/`) are generic enough that
"unlikely" would be an assertion, not a finding.
**The structural point we missed first time round.** The guard is a *persist* gate:
"is this content safe to persist?". Executable code carries its risk at
**execution**, not at persistence — a `.py` entirely safe to store may be dangerous
to run. So even a maximally strict persist gate does not cover the class §10
introduces, and the execution boundary has **no owner in this stack today**,
because upstream deferred it ("the attester ABI, portability, and sandboxing") and
we declared runtime out of scope on that same deferral. Recorded because "the guard
covers it" is a conclusion someone could reasonably draw and it would be wrong in a
way that is hard to detect later.
Our leaning, for them to accept or overrule: Door C should **refuse** a concept
whose frontmatter references an executor or attester resource that did not come
with it — failing closed, and half an Attested Computation is not something a
consumer can use anyway.
## TDD order
Steps 1–3 add tests and change no behavior, so they are safe first and de-risk