Extract TAP-framer into an independently pinned repository #483

New issue

Open

opened 2026-10-17 00:12:58 +00:00 by anton · 0 comments

anton commented

2026-10-17 00:12:58 +00:00

Owner

Context

Separate follow-up to #468 and Ryan's S7 / K8 review finding: #468 (comment). Keep this extraction out of the existing component-reuse PR.

At the reviewed implementation, TAP-framer's component specification uses the whole platform commit as its source revision, and API startup validates that revision against the platform framework pin. An unrelated platform release therefore changes the TAP component build identity even when its source is unchanged.

TAP-framer is already a standalone Rust crate with its own workspace and lockfile under src/tap-framer/, plus a dedicated containerfiles/Containerfile.tap-framer. It is a natural candidate for a separate public component repository, provisionally public/tap-framer. This issue requests that extraction and the platform integration; it does not create the repository or implement the migration.

Proposed change

Move the helper source, lockfile, component-level tests/protocol documentation and canonical reproducible Containerfile into the component repository. Preserve licensing, attribution and useful history. Retain platform-specific integration tests in platform; avoid independently maintained copies of the build recipe.
Add an explicit immutable TAP-framer source pin to platform's normal dependency resolution, for example TAP_FRAMER_COMMIT (proposed name, not an existing interface). Select an approved full commit once; do not resolve a floating branch/tag or automatically upgrade during application deployment.
Thread that identity through component preparation, API startup validation, local/remote builder staging, cache/spec construction, manifests and CLI source reproduction. Validate against the independently configured component pin, not the platform SHA or a claim supplied by the downloaded set itself.
Key the TAP component on its actual immutable build inputs: component source/locked dependencies, canonical recipe, toolchain/base-image pins, target and build options. An unrelated platform commit must not change this key. Keep the framework pin in the full EIF/application build identity wherever it remains an input. Merely relocating the files while retaining the old platform-dependent key is not sufficient.
Preserve automatic preparation/publication/pinning through the existing make up workflow and existing component storage/accepted-lock checks. No manual hash-pasting, new registry, new service release controller, or mandatory new bucket/role.

Compatibility and provenance

Preserve the deployed host/guest framing pair and existing egress policy. Extraction is not a protocol change; never silently pair an old EIF with the latest host helper or downgrade to raw transport.
Keep historical manifests/source layouts reproducible from their recorded platform revision. New manifests identify the separate component source unambiguously; preserve historical measured serialization and artifact retention. Do not rewrite historical manifests or substitute current sources.
Independently rebuild and verify candidate output; a source-layout move can change binary bytes even when Rust source is unchanged. Verify the selected host artifact before execution and retain strict component-digest and PCR checks. Guest attestation does not authenticate host execution.
Document the consuming API/CLI compatibility and paired upgrade/rollback procedure.

Acceptance criteria

The component builds and runs its focused tests independently from a clean checkout, using its checked-in production recipe and locked inputs.
Two platform revisions with identical TAP inputs produce the same TAP component specification/key and reuse the verified accepted artifact without recompiling it. A TAP source or other effective build-input change invalidates that key.
Component selection, startup validation and every builder/verifier path use the separate immutable pin; missing, mismatched or corrupt inputs fail closed.
Historical platform-embedded TAP deployments still reproduce from their original inputs, while new deployments reproduce from the separate repo. Source/prebuilt artifact and EIF/PCR equality is demonstrated, not inferred from unit tests.
On the approved dev environment, managed and BYOC deployments exercise the actual TAP egress path, host/guest pairing and strict uncached attestation. Include an egress-disabled case and a paired rollback case; retain exact-revision evidence and clean up only owned test resources.
Operator/component documentation and the release verification command cover source/recipe/output pin consistency without expanding into platform-wide CI or release-management redesign.

Trade-off / scope

A separate repo gives TAP-framer an independent release history and dependency pin, at the cost of an additional repository and coordinated cross-repo updates. A source-subtree-based key would be a smaller alternative if cache reuse were the only goal. The preferred direction here is extraction because this is already a standalone host/guest component; keep it a focused migration, not a networking rewrite or broader packaging project.

## Context Separate follow-up to #468 and Ryan's S7 / K8 review finding: https://git.caution.co/public/platform/pulls/468#issuecomment-933. Keep this extraction out of the existing component-reuse PR. At the reviewed implementation, TAP-framer's component specification uses the whole platform commit as its source revision, and API startup validates that revision against the platform framework pin. An unrelated platform release therefore changes the TAP component build identity even when its source is unchanged. TAP-framer is already a standalone Rust crate with its own workspace and lockfile under `src/tap-framer/`, plus a dedicated `containerfiles/Containerfile.tap-framer`. It is a natural candidate for a separate public component repository, provisionally `public/tap-framer`. This issue requests that extraction and the platform integration; it does not create the repository or implement the migration. ## Proposed change - Move the helper source, lockfile, component-level tests/protocol documentation and canonical reproducible Containerfile into the component repository. Preserve licensing, attribution and useful history. Retain platform-specific integration tests in platform; avoid independently maintained copies of the build recipe. - Add an explicit immutable TAP-framer source pin to platform's normal dependency resolution, for example `TAP_FRAMER_COMMIT` (proposed name, not an existing interface). Select an approved full commit once; do not resolve a floating branch/tag or automatically upgrade during application deployment. - Thread that identity through component preparation, API startup validation, local/remote builder staging, cache/spec construction, manifests and CLI source reproduction. Validate against the independently configured component pin, not the platform SHA or a claim supplied by the downloaded set itself. - Key the TAP component on its actual immutable build inputs: component source/locked dependencies, canonical recipe, toolchain/base-image pins, target and build options. An unrelated platform commit must not change this key. Keep the framework pin in the full EIF/application build identity wherever it remains an input. Merely relocating the files while retaining the old platform-dependent key is not sufficient. - Preserve automatic preparation/publication/pinning through the existing `make up` workflow and existing component storage/accepted-lock checks. No manual hash-pasting, new registry, new service release controller, or mandatory new bucket/role. ## Compatibility and provenance - Preserve the deployed host/guest framing pair and existing egress policy. Extraction is not a protocol change; never silently pair an old EIF with the latest host helper or downgrade to raw transport. - Keep historical manifests/source layouts reproducible from their recorded platform revision. New manifests identify the separate component source unambiguously; preserve historical measured serialization and artifact retention. Do not rewrite historical manifests or substitute current sources. - Independently rebuild and verify candidate output; a source-layout move can change binary bytes even when Rust source is unchanged. Verify the selected host artifact before execution and retain strict component-digest and PCR checks. Guest attestation does not authenticate host execution. - Document the consuming API/CLI compatibility and paired upgrade/rollback procedure. ## Acceptance criteria - [ ] The component builds and runs its focused tests independently from a clean checkout, using its checked-in production recipe and locked inputs. - [ ] Two platform revisions with identical TAP inputs produce the same TAP component specification/key and reuse the verified accepted artifact without recompiling it. A TAP source or other effective build-input change invalidates that key. - [ ] Component selection, startup validation and every builder/verifier path use the separate immutable pin; missing, mismatched or corrupt inputs fail closed. - [ ] Historical platform-embedded TAP deployments still reproduce from their original inputs, while new deployments reproduce from the separate repo. Source/prebuilt artifact and EIF/PCR equality is demonstrated, not inferred from unit tests. - [ ] On the approved dev environment, managed and BYOC deployments exercise the actual TAP egress path, host/guest pairing and strict uncached attestation. Include an egress-disabled case and a paired rollback case; retain exact-revision evidence and clean up only owned test resources. - [ ] Operator/component documentation and the release verification command cover source/recipe/output pin consistency without expanding into platform-wide CI or release-management redesign. ## Trade-off / scope A separate repo gives TAP-framer an independent release history and dependency pin, at the cost of an additional repository and coordinated cross-repo updates. A source-subtree-based key would be a smaller alternative if cache reuse were the only goal. The preferred direction here is extraction because this is already a standalone host/guest component; keep it a focused migration, not a networking rewrite or broader packaging project.