open/llm-ingestion-pipeline-security
1
0
Fork 0
Code Issues Releases 4 Activity
4 releases 14 tags
  • v1.1.0 ca4f97c8c9

    v1.1.0 Stable

    ktg released this 2026-08-13 20:58:49 +00:00 | 13 commits to main since this release

    No known key found for this signature in database

    [1.1.0] — 2026-08-13

    Fixed — a mapping construct in OKF frontmatter no longer degrades into a string

    okf.parse_frontmatter gives the mapping class no expressible form by design
    (T2). Two routes escaped that: they parsed "successfully" into the wrong type
    instead of raising. Both are closed, and both now FAIL_SECURE through
    okf.import_bundle (door C).

    route was now
    sources:
    - uri: https://e.com/a    		 string 'uri: https://e.com/a' — WARN OKFFrontmatterError — FAIL_SECURE
    sources:
    - uri:    		 string 'uri:' — WARN OKFFrontmatterError — FAIL_SECURE
    attester: resource: attesters/x.py string 'resource: attesters/x.py' — WARN OKFFrontmatterError — FAIL_SECURE

    The security consequence was the same in each: a pointer parked in a degraded
    mapping rides through in a key the resource allowlist never inspects, and mode-b
    import_bundle writes the merged concept verbatim. The first route was documented
    at docs/LIMITATIONS.md:43; the inline second colon was found by measurement
    while closing it    , and is the reason this release names two routes rather than one.
    Neither shape is conformant OKF — a well-formed bundle does not produce them; a
    malformed or hostile one can.

    What closed is the type confusion, not pointer-smuggling as a class. T3 still
    inspects resource and nothing else, so an honest string under another key rides
    through exactly as before: attester: attesters/sql_equality.py is WARN, while
    the same path under resource: FAIL_SECUREs. The string is still scanned like any
    other frontmatter value under T1. Nothing about that changed here.

    The boundary is where YAML puts it, ground-truthed against PyYAML 6.0.3 rather
    than reasoned: ": " and a trailing ":" are exactly the two shapes where a plain
    scalar becomes a mapping, and they are refused. A colon carrying neither a space nor
    a line end opens no mapping — domain:security and https://e.com:8443/a still
    parse — and a quoted scalar (- "uri: x") is still a scalar. Quotes are retained
    rather than stripped; that divergence from YAML is unchanged and now pinned.

    This is a behaviour change inside the freeze, not a break of it. No exported
    name moved. A document that disposed WARN on 1.0.0 may dispose FAIL_SECURE
    here — the 1.0.0 entry says exactly this is a fix, not a break. A consumer whose
    bundles carry an unquoted ": " in a frontmatter value will now see those concepts
    refused at import; quote the value, and it parses.

    Suite 792 → 802: 13 rows added (4 rejected shapes, 7 admitted ones, 2 through
    import_bundle), 3 retired (the two that pinned the defect, and the one-key row
    in the block-list table). 129/129 classes, 6/6 documented gaps, 35 limitations —
    all unchanged.

    Downloads