tegwick
f88a92fb37
glas-harness asked for a scanned immutable image. The scan ran, and it failed on the base we had sanctioned, so no image was pushed. Every finding is inherited from the base image or its distro packages; none is in approval_engine code. Two fixes applied here: The base pin was stale. It named a Debian 13.5 build of python:3.12-slim while upstream is 13.6. Bumping the digest removes 30 HIGH and 47 MEDIUM on its own. Still a digest, not a floating tag. pip is gone from the runtime image. All 10 MEDIUM Python findings were in pip itself, a build-time tool with no business in a running approval service. The build is now two-stage, and pip is removed from both the venv and the base's /usr/local, so command -v pip returns nothing. What remains is a decision rather than a task. Three CRITICALs persist on Debian, all perl-base (CVE-2026-13221, CVE-2026-42496, CVE-2026-8376), none with an upstream fix, in a package this service never invokes and that Debian marks Essential. An Alpine variant carries no perl and scans 0 CRITICAL / 7 HIGH / 1 MEDIUM against Debian's 3 / 51 / 56. Alpine is proven viable rather than asserted: musl wheels resolve with no toolchain, the full suite passes on musl at 111 tests, and non-root uid 10001, schema v3, tenant:platform, fresh-store migrate/verify and both production fail-closed gates all hold in the built image. It is parked in Containerfile.alpine as a candidate; Containerfile remains sanctioned. Nothing was released. Pushing the Debian variant would pin three unfixable CRITICALs into a release digest, and choosing the runtime C library for this service is not a call to make silently. The manifest still carries REPLACE_WITH_RELEASE_DIGEST. Full record in docs/image-scan-2026-09-06.md. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PM5HnEAhokxdfcPqBNpT7D Assistant: claude-code Assistant-Model: opus Assistant-Process: 715850@bnt-lap001 Assistant-Session: eb557e93-7cb1-45d0-9e57-7d15b3edc60e |
||
|---|---|---|
| approval_engine | ||
| deploy | ||
| docs | ||
| examples | ||
| history | ||
| intakes | ||
| schemas | ||
| tests | ||
| workplans | ||
| .custodian-brief.md | ||
| .gitignore | ||
| .repo-classification.yaml | ||
| AGENTS.md | ||
| cadence.yaml | ||
| Containerfile | ||
| Containerfile.alpine | ||
| INTENT.md | ||
| layer.yaml | ||
| Makefile | ||
| pyproject.toml | ||
| README.md | ||
| SCOPE.md | ||
| WORK-RECORDS.md | ||
approval-engine
The approval as a durable, authenticated, consumable object — issued before an action, verified at the moment of use, and provably not replayable.
An Engine, role PIP, in the NetKingdom security layer model (statute v0.7,
accepted; operative form net-kingdom/SECURITY-COMPANION.md). It answers one
question, totally and decidably:
Is this approval valid right now — for this exact action, target, actor, and purpose — and has it already been used?
It does not decide whether the action is permitted. That is access-engine,
which stays NetKingdom's only policy decision point. An approval is one input to
that decision.
Deliberately small, boring, and strict: atomic supersession and single
consumption are what make Canon test T-06 — Approval Replay passable.
Flexibility here would be a defect. Graded, evidence-based progression belongs to
maturity-engine; the two engines are deliberate opposites.
See INTENT.md and SCOPE.md. Declaration: layer.yaml.
Claim: docs/approval-claim.md.
Consume: docs/approval-consumption.md.
Caller auth: docs/caller-authentication.md.
PEP sequence: docs/pep-integration.md.
Origin: flex-auth FLEX-DEC-2026-001, raised while assenting to the security
layer model.
make test
approval-engine migrate --db approvals.sqlite
approval-engine verify --db approvals.sqlite
approval-engine serve --db approvals.sqlite \
--jwt-issuer https://auth.netkingdom.local \
--jwt-audience approval-engine \
--jwks-url http://key-cape.sso.svc.cluster.local:8080/jwks
POST /v1/approvals/{id}/consume implements GH-DEC-2026-003: the PEP
atomically spends the approval before the protected side effect. Same-digest
retries are idempotent; a different digest conflicts.
Production operations, caller scopes, audit delivery, and PEP sequencing are
documented in docs/storage-operations.md, docs/caller-authentication.md,
docs/outbox-contract.md, and docs/pep-integration.md. The checked-in
StatefulSet deliberately refuses production startup without a migrated
persistent store, KeyCape JWT verification, and authenticated audit delivery.