open/llm-ingestion-pipeline-security
1
0
Fork 0
Code Issues Releases 5 Activity

docs: finish the 1.4.0 release on the doc surfaces

Browse source 
The 1.4.0 release commit (d19de8c) dated the CHANGELOG heading and nothing
else, so the tag went out with README, ADOPTION-BRIEF and BRIEF still
naming 1.3.0 and the install pin still installing 1.3.0. This bumps the
badge, status line and install pin in README, the status and "as of"
lines in ADOPTION-BRIEF (test count 868 -> 893) and BRIEF's status line.
The tag itself is not moved.

Three claims that went false earlier are corrected against the code:

- README said `resource` is deliberately not on the frontmatter allowlist
  and that a `sources` block list of mappings is refused. Both stopped
  being true in 1.3.0. The paragraph now names the four mapping carriers
  and says `resource` / `usage_window` are admitted inside a `sources`
  entry only.
- README described the `resource` https-allowlist without its scope. It
  covers the top-level `resource` only; `sources[].resource` is never
  URL-validated (measured: `javascript:` there imports with no error).
- LIMITATIONS still listed `tags: [a, b]` among the routes that fail.
  It parses since 1.4.0.

Gates after the edit: 893 passed, coverage exit 0, redos-sweep exit 0,
45 LIMITATIONS entries.
This commit is contained in:
Kjell Tore Guttormsen 2026-09-23 12:25:33 +02:00
commit 79285e1265
Signed by: ktg
SSH key fingerprint: SHA256:JakMjO6FTBBzN0Bhfj9saOoEjaFxlSdYuZQQpM/lF9Q
5 changed files with 30 additions and 25 deletions
Download patch file Download diff file Expand all files Collapse all files

30
README.md
View file

@ -2,7 +2,7 @@
Write-time defensive layer for Python pipelines that persist LLM output: sanitize, fence, tool-less quarantined transform, capability isolation, scan before persist, fail-secure.
![Version](https://img.shields.io/badge/version-1.3.0-blue)
![Version](https://img.shields.io/badge/version-1.4.0-blue)
![Status](https://img.shields.io/badge/status-stable-brightgreen)
![Python](https://img.shields.io/badge/python-3.10%2B-purple)
![License](https://img.shields.io/badge/license-MIT-lightgrey)
@ -33,7 +33,7 @@ at write time, never assumed from the format. Any pipeline ingesting external da
into an agent-read store has this shape; an OKF wiki is its canonical form — which
is why the guard ships a first-class OKF adapter (below).
**Status:** `v1.3.0`. The stdlib-only core — its detector, contract, and
**Status:** `v1.4.0`. The stdlib-only core — its detector, contract, and
OKF-adapter modules plus the top-level wiring — is built and tested, exercised by
an end-to-end showcase and adversarial + false-positive corpora. The exported
Python surface is now frozen under semver: nothing exported is removed, renamed or
@ -58,7 +58,7 @@ are real limitations, stated plainly below; read them.
Not on PyPI. The guard is distributed from its Forgejo origin — pin a release tag:
```bash
pip install "llm-ingestion-guard @ git+https://git.fromaitochitta.com/open/llm-ingestion-pipeline-security.git@v1.3.0"
pip install "llm-ingestion-guard @ git+https://git.fromaitochitta.com/open/llm-ingestion-pipeline-security.git@v1.4.0"
```
The `open/` mirror is anonymously readable, so CI needs no deploy key, token, or
@ -165,20 +165,26 @@ Per-concept gates: **path / reserved-name** (rejects `..` traversal and reserved
reject-by-default loader that refuses anchors, aliases, and explicit tags *by
construction*, so a billion-laughs alias expansion or a `!!python/object` coercion
cannot occur (it is deliberately **not** a general YAML engine, whose own features
are the attack surface). The one mapping form it accepts is OKF v0.2's flow
mapping — `generated: { by: x, at: y }`, `verified: { … }` bare or listed,
`usage_window: { from: …, to: … }` — admitted key-by-key against a nine-name
allowlist (`by`, `at`, `from`, `to`, `id`, `title`, `author`, `usage_count`,
`last_modified`) with plain-scalar leaves only. A key off that list, a nested
collection or a duplicate key is refused, and `resource` is deliberately not on
it; the block, dotted and inline-colon routes to a mapping still raise. A
are the attack surface). A mapping has four carriers: the flow mapping as a value
(`generated: { by: x, at: y }`) or as a block-list item, a flow sequence of flow
mappings (`sources: [{ id: a, resource: x }]`), and a block sequence of block
mappings (SPEC §5.1's own form). Every carrier is admitted key-by-key against a
nine-name allowlist (`by`, `at`, `from`, `to`, `id`, `title`, `author`,
`usage_count`, `last_modified`) with plain-scalar leaves only; `resource` and
`usage_window` are admitted *inside a `sources` entry only*, so an `executor` or
`attester` `resource` is refused through every carrier. A key off that list, a
nested collection or a duplicate key is refused; a top-level block mapping and
the dotted and inline-colon routes to a mapping still raise. A
*sequence* value has two carriers — the block list, and (as of `1.4.0`) the flow
sequence `tags: [a, b, c]`, which is SPEC §4.1's own skeleton — whose elements
are either all plain scalars or all flow mappings, never a mix. A scalar element
carrying any of `{ } [ ] : , " ' #` is refused rather than guessed at. See
[LIMITATIONS](docs/LIMITATIONS.md) for what that admits and what it still walls
off (a `sources` block list of mappings is still refused); **`resource` https-allowlist** (hard-rejects
`data:`/`javascript:`/`file:` before commit — a reject-gate, not defang);
off; **`resource` https-allowlist** (hard-rejects
`data:`/`javascript:`/`file:` before commit — a reject-gate, not defang — on the
top-level `resource` only: a `sources[].resource` is never URL-validated, because
SPEC §5.1 allows bundle-relative paths there, so a consumer that follows it calls
`validate_resource_url` itself);
**whole-concept scan** (frontmatter *values* + body through `scan_output`);
**cross-link graph** (surfaces dangling targets, the dormant-injection signal, and
rejects bundle-escaping links); **provenance stamping** (`Origin` × `Channel` →