[FEATURE] Admit declared tool payloads through four isolated image profiles #4

New issue

Open

opened 2026-09-12 07:56:23 +02:00 by erikinkinen · 0 comments

erikinkinen commented

2026-09-12 07:56:23 +02:00

Owner

Problem and motivation

Self-hosting needs imported development tools while trusted EriX implementation and clean images retain clean-room provenance. Packaging must distinguish the two and reject undeclared transitive runtime payloads.

Proposed behavior and scope

Implement versioned payload manifests, offline source/recipe records, explicit extended-dev and extended-release profiles, a reviewed release subset, and independent closure/contamination tests across all four image profiles. Keep every imported dependency traceable to a required tool.

This issue records planned work; its unchecked criteria are not implementation proof. The normative basis is Phase 6 and AC1–AC24.

Authority, security and reliability

Extended-image selection grants no device, raw-block, key, global-discovery or network access. Place admitted executable/library objects on ext4 with exact manifests and realm policy. Imported libraries cannot become dependencies of trusted clean-room Rust components.

Apply the priority order: security, reliability, then performance. Keep suspected vulnerabilities in the repository’s restricted SECURITY.md reporting channel.

Acceptance criteria

Implement a versioned third-party payload manifest containing name, version, source
digest, license/notices, target, recipe/patch digests, features, runtime dependency closure,
dynamic dependencies and realm authority policy.
Define offline source ingestion and reproducible recipe storage; keep imported
sources/patches separate from EriX-authored ISC implementation and never add imported
libraries to trusted EriX Cargo dependencies.
Add explicit runtime.extended-dev.toml and runtime.extended-release.toml,
labeled non-clean-room in metadata/output. Preserve existing clean runtime.dev.toml and
runtime.release.toml semantics.
Enforce clean-profile exclusion across configuration inheritance, local overrides,
aliases, caches, transitive libraries and packaged contents; test intentional imported-payload
contamination fails closed.
Enforce a reviewed extended-release subset; exclude development-only
generators/test harnesses/debuggers and unneeded dependency libraries.
Verify every admitted target ELF and declared DT_NEEDED closure,
source/license/recipe record and authority envelope; reject unknown payloads, mismatched
targets, dependency-only orphans and mutable unpinned sources.
Reconcile the phase inventory with newly discovered packaging and documentation
dependencies before admission; update normative inventory, manifest schema/records and tests
rather than silently expanding imports.
Package admitted tools on ext4 with bounded executable/library manifests; the build
realm gets no raw block/device/key/global discovery or network capability from extended-image
selection.
Test all four profile builds, labels, artifact inventories and clean-room exclusion
independently; extended-tool success never certifies clean-room implementation provenance.

For each implementation slice, retain actual formatting, strict Clippy, unit/doctest and warning-denied build results for all altered Rust repositories and valid configurations. Add relevant runtime VM coverage, monitor older unit/VM regressions in exact-head CI, and update canonical component documents and affected technical-manual/API material. Every authored code file must remain below 1,000 physical lines, with meaningful inline documentation and missing_docs enforcement in Rust crates.

Alternatives and tradeoffs

Unlabeled mixed images obscure both licensing and security boundaries. Preserve clean profile semantics and use a separate manifest-controlled extended closure rather than broad configuration inheritance.

Tracking and rollout

Dependencies: integration#1

Dependencies identify required contracts and closure gates; preparatory inventory/design can proceed in parallel under one owner per edited file. Link bounded implementation issues and their PRs here before claiming acceptance. Use feature/posix-compat, regular signed commits in the canonical contribution format, and WIP PRs linked to the exact coherent component graph. All cross-repository Cargo/catalog selections and CI helpers use full 40-character lowercase commit hashes, including transitive dependencies; do not substitute branch, tag or implicit HEAD selection.

Close criteria only with their own reviewed deliverables and validation evidence. Pending, skipped, cancelled, failed or predecessor-only results remain distinct. Keep main images unchanged until explicit promotion direction; technical completion does not authorize merges, release tags or publication.

## Problem and motivation Self-hosting needs imported development tools while trusted EriX implementation and clean images retain clean-room provenance. Packaging must distinguish the two and reject undeclared transitive runtime payloads. ## Proposed behavior and scope Implement versioned payload manifests, offline source/recipe records, explicit extended-dev and extended-release profiles, a reviewed release subset, and independent closure/contamination tests across all four image profiles. Keep every imported dependency traceable to a required tool. This issue records planned work; its unchecked criteria are not implementation proof. The normative basis is [Phase 6 and AC1–AC24](https://git.erikinkinen.fi/erix/docs/src/branch/main/phases/6.md). ## Authority, security and reliability Extended-image selection grants no device, raw-block, key, global-discovery or network access. Place admitted executable/library objects on ext4 with exact manifests and realm policy. Imported libraries cannot become dependencies of trusted clean-room Rust components. Apply the priority order: security, reliability, then performance. Keep suspected vulnerabilities in the repository’s restricted SECURITY.md reporting channel. ## Acceptance criteria - [ ] Implement a versioned third-party payload manifest containing name, version, source digest, license/notices, target, recipe/patch digests, features, runtime dependency closure, dynamic dependencies and realm authority policy. - [ ] Define offline source ingestion and reproducible recipe storage; keep imported sources/patches separate from EriX-authored ISC implementation and never add imported libraries to trusted EriX Cargo dependencies. - [ ] Add explicit `runtime.extended-dev.toml` and `runtime.extended-release.toml`, labeled non-clean-room in metadata/output. Preserve existing clean `runtime.dev.toml` and `runtime.release.toml` semantics. - [ ] Enforce clean-profile exclusion across configuration inheritance, local overrides, aliases, caches, transitive libraries and packaged contents; test intentional imported-payload contamination fails closed. - [ ] Enforce a reviewed extended-release subset; exclude development-only generators/test harnesses/debuggers and unneeded dependency libraries. - [ ] Verify every admitted target ELF and declared DT_NEEDED closure, source/license/recipe record and authority envelope; reject unknown payloads, mismatched targets, dependency-only orphans and mutable unpinned sources. - [ ] Reconcile the phase inventory with newly discovered packaging and documentation dependencies before admission; update normative inventory, manifest schema/records and tests rather than silently expanding imports. - [ ] Package admitted tools on ext4 with bounded executable/library manifests; the build realm gets no raw block/device/key/global discovery or network capability from extended-image selection. - [ ] Test all four profile builds, labels, artifact inventories and clean-room exclusion independently; extended-tool success never certifies clean-room implementation provenance. For each implementation slice, retain actual formatting, strict Clippy, unit/doctest and warning-denied build results for all altered Rust repositories and valid configurations. Add relevant runtime VM coverage, monitor older unit/VM regressions in exact-head CI, and update canonical component documents and affected technical-manual/API material. Every authored code file must remain below 1,000 physical lines, with meaningful inline documentation and missing_docs enforcement in Rust crates. ## Alternatives and tradeoffs Unlabeled mixed images obscure both licensing and security boundaries. Preserve clean profile semantics and use a separate manifest-controlled extended closure rather than broad configuration inheritance. ## Tracking and rollout Dependencies: [integration#1](https://git.erikinkinen.fi/erix/integration/issues/1) Dependencies identify required contracts and closure gates; preparatory inventory/design can proceed in parallel under one owner per edited file. Link bounded implementation issues and their PRs here before claiming acceptance. Use `feature/posix-compat`, regular signed commits in the canonical contribution format, and WIP PRs linked to the exact coherent component graph. All cross-repository Cargo/catalog selections and CI helpers use full 40-character lowercase commit hashes, including transitive dependencies; do not substitute branch, tag or implicit HEAD selection. Close criteria only with their own reviewed deliverables and validation evidence. Pending, skipped, cancelled, failed or predecessor-only results remain distinct. Keep main images unchanged until explicit promotion direction; technical completion does not authorize merges, release tags or publication.

erikinkinen added the

security

phase-6

enhancement

labels

2026-09-12 07:56:23 +02:00

erikinkinen referenced this issue

2026-09-12 07:56:29 +02:00

[FEATURE] Run the complete admitted compiler and development toolchain inside EriX #7

erikinkinen referenced this issue

2026-09-12 07:56:30 +02:00

[FEATURE] Build and assemble the entire EriX product graph within a confined guest realm #8

erikinkinen referenced this issue

2026-09-12 07:56:30 +02:00

[FEATURE] Demonstrate two complete generations of EriX built inside EriX #9

erikinkinen referenced this issue

2026-09-12 07:56:30 +02:00

[FEATURE] Close final security, documentation, CI and self-hosting acceptance #10

erikinkinen changed title from ~~[FEATURE] [P13] Admit declared tool payloads through four isolated image profiles~~ to [FEATURE] Admit declared tool payloads through four isolated image profiles

2026-09-12 08:02:02 +02:00

erikinkinen referenced this issue

2026-09-19 11:36:52 +02:00

[FEATURE] Track Phase 6 POSIX compatibility and full EriX self-hosting #65