[FEATURE] Enforce firmware-to-rootfs signatures and scoped signing of build outputs #1

New issue

Open

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

erikinkinen commented 2026-09-12 07:56:24 +02:00

Owner

Copy link

Problem and motivation

Boot-image authentication alone does not protect EFI loading or every authority-bearing rootfs object. Generated programs and downloadable artifacts need an explicit signing/admission chain that does not expose private signer authority to builds.

Proposed behavior and scope

Define an acyclic finalization/signing graph, verify all policy/code/dependency objects, implement custom-key UEFI Secure Boot and protected CI signing, and exercise rotation, revocation and recovery. Separately define authenticated container bounds for unsigned convenience preferences and signed optional logo content.

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

Separate firmware, boot/rootfs, development and release keys and signer roles. Verify exact bytes before policy application or execution, bind verification to use, and retire scoped grants. Unsigned preferences may select packaged keyboard data but cannot change trust, executable selection or capability policy. Real firmware/key enrollment requires explicit owner approval.

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

Acceptance criteria

• Inventory the complete trust chain and all authority-controlling root-partition
  files: executables, libraries, scripts/interpreters, plugins, loader/runtime/launch manifests,
  service/mount/realm policies, key policy and configuration/includes that can change authority.
  No code object is exempt because it is imported, generated at runtime or not marked
  executable.
• Define verification ownership and an authenticated chain from enrolled firmware
  trust to EFI loader, boot.img, rootfs policy and every admitted executable/library. Existing
  bare digests are not the requested signature proof.
• Specify a per-file signature or signed catalogue entry authenticating exact final
  bytes, length, role, relevant metadata/path binding, format/version, dependency closure and
  signer/policy generation. Every covered file must have verifiable signed coverage; unsigned
  sidecar hashes are insufficient.
• Specify an acyclic finalization/signing DAG: finish code generation, stripping and
  capacity/metadata patches before object signatures, finalize authority catalogues before their
  boot trust anchor, then sign/package final EFI/boot/disk outputs. Avoid circular digest
  dependencies and post-sign edits.
• Separate firmware PK/KEK/db/dbx certificates/keys from boot/rootfs signing keys and
  development/build-realm keys; document trust roots, allowed signer roles, rotation/revocation
  and recovery without reusing a general key.
• Implement signed authority-file generation and verification in maintained tooling
  with independent known-answer, malformed-format, wrong-role, wrong-key, truncation, tampering
  and signature-coverage tests.
• Verify policy bytes before applying policy or delegating authority; verify
  executables and complete library/interpreter/module closures before execution/initializers.
  Integrity or signer identity alone grants no capability.
• Preserve fresh-object binding from signature verification to use; reject
  replacement, symlink/race/substitution and stale cache attacks, including lazily read
  executable pages and reused file handles. Never verify one object and map/execute another or
  mutable bytes from the same reopened path.
• Define authorized policy/code update and rollback behavior with atomic verified
  publication, cache invalidation, revocation and interrupted update recovery. Do not promise
  anti-rollback without a reviewed trusted version/revocation anchor beyond attacker-replaceable
  disk data.
• Define scoped signing/admission for newly built test programs, Cargo build scripts,
  proc macros, plugins and compiler outputs before executing them. Bind development signatures
  to the build realm/output policy; no unsigned output exception or general trusted-system
  signing oracle is allowed. Separate transient realm-generation-bound admission from
  reproducible final artifact signatures under fixed declared keys/policy; do not normalize away
  unexpected final signature differences in integration#9.
• Implement the build-output signing route with exact artifact identity, authorized
  operation, finite lifetime and complete cleanup; keep private key material out of ordinary
  build processes and boot-tool itself.
• Add rootfs tamper VMs for every object/policy class, missing/wrong/ revoked
  signatures, catalogue substitution, mixed generations and dependency replacement; prove no
  code runs and no new authority is installed on failure.
• Add an explicit CI signing configuration using a private key from Forgejo secrets
  for downloadable boot.img; separate local test-key builds from protected signed publication
  and fail closed when required secrets are missing. Never silently fall back to the repository
  test key for downloads.
• Restrict signing secrets to approved trusted workflow/ref contexts and an isolated
  signing stage consuming immutable verified artifacts; untrusted PR/fork code and ordinary
  compile/test scripts receive no signing key.
• Pass secrets through a reviewed non-logging channel to the narrow signer, scrub
  owned temporary material on success/failure/cancellation and exclude it from caches, dumps,
  job logs and uploaded artifacts. Verify secret absence without printing/search-reporting its
  actual bytes.
• Preserve boot-tool's detached payload/signature/verification contract; record
  public key fingerprint, exact signing payload/artifact hashes, source graph and signing policy
  without exposing private credentials.
• Publish an explicitly named signed boot.img plus verification material/provenance
  per profile/key cohort, and ensure every downloadable disk contains its corresponding exact
  tested signed payload and rootfs authority closure; verify downloaded bytes independently of
  local publisher status. Protected CI re-signing/repackaging creates a separately
  verified/tested cohort, not a byte-identical integration#9 result or permission for hidden host build
  completion.
• Test protected signing success, missing/wrong secret, untrusted-ref denial,
  modified input, signer failure and cancellation; publication must stop on failure and no
  unsigned/test-key output may be mislabeled trusted.
• Implement full supported-platform UEFI Secure Boot packaging with a custom
  EriX/user-controlled certificate: sign the PE/COFF EFI loader in the firmware-required format
  and keep its verification material consistent with boot/rootfs trust. An Ed25519 boot.img
  signature is not firmware EFI signing.
• Provide documented custom PK/KEK/db/dbx enrollment, owner-authorized updates,
  certificate distribution and revocation/recovery procedures without dependence on a Microsoft
  signature. Back up existing enrollment and require explicit approval before changing real
  firmware variables or owner keys.
• Define enforced versus explicitly non-enforced development boot modes and check
  SecureBoot/SetupMode state where appropriate; never report successful enforcement while
  firmware is in setup mode or validation is off.
• Add QEMU/OVMF Secure Boot fixtures with private firmware-variable storage and
  custom enrollment; prove correct-key boot and refusal of unsigned, wrong-key, tampered and
  revoked EFI images without a permissive fallback path.
• Exercise the full enforced chain with tampered boot.img, rootfs policies,
  executables and shared libraries; firmware success alone cannot close downstream verification
  gates. Include both clean and extended profiles.
• Test key rotation/revocation, interrupted updates and documented recovery using
  independent fixtures, preserving least authority and a usable owner recovery path rather than
  silently disabling verification.
• Perform a manually approved real-firmware enrollment/boot/rejection validation on
  the supported hardware baseline; record firmware versions and limitations. OVMF evidence alone
  is not a claim of universal firmware support.
• Audit signing/verification code and CI boundaries independently, update threat
  models/rustdoc/man/manual and include malformed crypto/container inputs without introducing
  third-party code into clean-room components.
• Verify normal signed loading does not retain signer/admin authority in loaders or
  applications; profile verification overhead through integration#3 and optimize only exact immutable
  identities with sound invalidation.
• Include signing/trust tests in the full CI and both integration#9 build generations, using
  scoped development keys for self-host proof and protected CI signing for downloadable outputs;
  document the distinct trust policies.
• Produce an operator verification/enrollment/recovery runbook and alpha-review
  evidence showing the exact EFI→boot→rootfs trust chain, public verification keys and download
  hashes, with no private signing material.
• Design/version a distinct unsigned user-preference section in boot.img,
  separate from signed executable/configuration/authority data. Whitelist non-authoritative
  typed settings, initially keyboard-layout ID; preferences cannot select trust roots, bypass
  verification, choose executables, alter capability/realm policy or grant device/namespace
  access.
• Authenticate the container format and section directory/bounds, including the
  precise permitted unsigned extent. Exclude only that preference payload from the boot
  signature's authenticated message; verify every security- relevant byte and reject overlap,
  aliasing, truncation, confused versions and attempts to reinterpret signed bytes as
  preferences. Give the preference descriptor an authenticated explicit hash policy: no signed
  section hash may still depend on mutable preference bytes. Any optional corruption checksum
  for those bytes lives inside their unsigned extent.
• Implement build/read/update tooling for preferences without private signing
  authority, preserving all authenticated bytes, section extents and signatures. Record separate
  full-container digest and signed-content identity: preference edits change the former, not the
  latter; refresh local artifact receipts without falsely claiming an edited image matches
  published checksums. Coordinate any outer boot-image/catalog authentication so it anchors
  signed core identity, not a whole-file digest that silently forbids unsigned edits; retain
  whole-file digests as exact distribution/integrity evidence.
• Parse preferences as bounded untrusted input with deterministic
  absent/malformed/unsupported-value handling, defaulting keyboard layout to en_US. Malformed
  preference content may fall back, but malformed authenticated structure or signature failure
  must still fail closed, never enter fallback.
• Carry the validated preference value to its consumers as explicitly
  non-authoritative data, distinct from trusted clear-completion and authority handoff fields.
  Only select packaged, signed, allowlisted keyboard definitions; preference text cannot load a
  script, plugin, arbitrary path or mapping code.
• Add signature/container unit tests and VMs showing layout-only preference edits
  preserve Secure Boot/boot-content verification, while changing signed code, policy, bounds,
  key selection or verification flags is rejected. Test integer overflow, unknown/duplicate
  keys, padding and recovery defaults.
• Version boot-image/handoff parsing and every consumer's trust classification for
  unsigned preferences; do not reuse MUTABLE_AFTER_BOOT or descriptors promising all bytes
  were signature-verified as an unsigned bypass. Update format/coverage vectors,
  boot-tool/manual docs and negative version tests together, then retire superseded intake under
  integration#2 without a permissive fallback.
• Keep the optional boot-logo bitmap and its type/dimensions/format under signed
  boot-image coverage, separate from unsigned user preferences; decode/render it only after
  authentication. Logo substitution cannot extend the unsigned region, select executable content
  or alter authority handoff.

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

Bare digests and successful firmware boot are insufficient for downstream signed coverage; anti-rollback also needs a real trusted version anchor. Protected CI re-signing is a separately verified cohort and cannot conceal a host build step in the two-generation proof.

Original realm image UEFI prerequisite — 18 September 2026: Signed acc1e734f79366e965b7ab7cd41496afddc6b1fe adopts the original dynamic-link contract dependency. Four default/all-feature development/release Rust configurations, four UEFI builds with fatal linker warnings, strict host/UEFI Clippy, formatting and private rustdoc pass. All 53 Python fixture controls and the explicit signing authority checks pass. The emitted console debug EFI/PDB association and release artifact tree pass inspection with zero warnings. Direct implementation bytes are unchanged. Original CI must still accept both exact source-pair profiles and deliberate release diagnostics; coherent image and full guest-build acceptance remain separate requirements.

Original coherent realm source CI acceptance — 18 September 2026: Signed acc1e734f79366e965b7ab7cd41496afddc6b1fe passes CI 142 and CI 141. All four terminal logs are complete (144,166 bytes), with zero final warnings. This closes the original CI observation recorded above. Coherent catalog publication, actual consumer VMs and full guest-build acceptance remain separate open requirements.

Tracking and rollout

Command and boot dependency alignment — 15 September 2026

Signed d48450b6bbccc80cbae3cfcf2feece3e6b04a347 aligns the existing dependency selections with the original signed runtime graph. This checkpoint changes Cargo selections and the roadmap; this repository's Rust implementation files are unchanged. Formatting, strict Clippy, private rustdoc and canonical documentation checks pass without warnings. Default/all-feature development/release tests pass 41 default / 41 all-feature tests. All four host and UEFI configurations build successfully, including the supported make entry point. Signing-authority checks and 53 source/artifact/profile-owner fixture tests pass, as does private build-script documentation. The exact committed source-pair reproducibility, default/console EFI/PDB profiles and deliberate release-diagnostic checks pass in both component CI runs. Push/review CI 139/140 passes with complete classified logs and no final warnings. The product catalog, product VM acceptance and guest build remain pending. Review: #3.

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 Boot-image authentication alone does not protect EFI loading or every authority-bearing rootfs object. Generated programs and downloadable artifacts need an explicit signing/admission chain that does not expose private signer authority to builds. ## Proposed behavior and scope Define an acyclic finalization/signing graph, verify all policy/code/dependency objects, implement custom-key UEFI Secure Boot and protected CI signing, and exercise rotation, revocation and recovery. Separately define authenticated container bounds for unsigned convenience preferences and signed optional logo content. 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 Separate firmware, boot/rootfs, development and release keys and signer roles. Verify exact bytes before policy application or execution, bind verification to use, and retire scoped grants. Unsigned preferences may select packaged keyboard data but cannot change trust, executable selection or capability policy. Real firmware/key enrollment requires explicit owner approval. Apply the priority order: security, reliability, then performance. Keep suspected vulnerabilities in the repository’s restricted SECURITY.md reporting channel. ## Acceptance criteria - [ ] Inventory the complete trust chain and all authority-controlling root-partition files: executables, libraries, scripts/interpreters, plugins, loader/runtime/launch manifests, service/mount/realm policies, key policy and configuration/includes that can change authority. No code object is exempt because it is imported, generated at runtime or not marked executable. - [ ] Define verification ownership and an authenticated chain from enrolled firmware trust to EFI loader, boot.img, rootfs policy and every admitted executable/library. Existing bare digests are not the requested signature proof. - [ ] Specify a per-file signature or signed catalogue entry authenticating exact final bytes, length, role, relevant metadata/path binding, format/version, dependency closure and signer/policy generation. Every covered file must have verifiable signed coverage; unsigned sidecar hashes are insufficient. - [ ] Specify an acyclic finalization/signing DAG: finish code generation, stripping and capacity/metadata patches before object signatures, finalize authority catalogues before their boot trust anchor, then sign/package final EFI/boot/disk outputs. Avoid circular digest dependencies and post-sign edits. - [ ] Separate firmware PK/KEK/db/dbx certificates/keys from boot/rootfs signing keys and development/build-realm keys; document trust roots, allowed signer roles, rotation/revocation and recovery without reusing a general key. - [ ] Implement signed authority-file generation and verification in maintained tooling with independent known-answer, malformed-format, wrong-role, wrong-key, truncation, tampering and signature-coverage tests. - [ ] Verify policy bytes before applying policy or delegating authority; verify executables and complete library/interpreter/module closures before execution/initializers. Integrity or signer identity alone grants no capability. - [ ] Preserve fresh-object binding from signature verification to use; reject replacement, symlink/race/substitution and stale cache attacks, including lazily read executable pages and reused file handles. Never verify one object and map/execute another or mutable bytes from the same reopened path. - [ ] Define authorized policy/code update and rollback behavior with atomic verified publication, cache invalidation, revocation and interrupted update recovery. Do not promise anti-rollback without a reviewed trusted version/revocation anchor beyond attacker-replaceable disk data. - [ ] Define scoped signing/admission for newly built test programs, Cargo build scripts, proc macros, plugins and compiler outputs before executing them. Bind development signatures to the build realm/output policy; no unsigned output exception or general trusted-system signing oracle is allowed. Separate transient realm-generation-bound admission from reproducible final artifact signatures under fixed declared keys/policy; do not normalize away unexpected final signature differences in [integration#9](https://git.erikinkinen.fi/erix/integration/issues/9). - [ ] Implement the build-output signing route with exact artifact identity, authorized operation, finite lifetime and complete cleanup; keep private key material out of ordinary build processes and `boot-tool` itself. - [ ] Add rootfs tamper VMs for every object/policy class, missing/wrong/ revoked signatures, catalogue substitution, mixed generations and dependency replacement; prove no code runs and no new authority is installed on failure. - [ ] Add an explicit CI signing configuration using a private key from Forgejo secrets for downloadable `boot.img`; separate local test-key builds from protected signed publication and fail closed when required secrets are missing. Never silently fall back to the repository test key for downloads. - [ ] Restrict signing secrets to approved trusted workflow/ref contexts and an isolated signing stage consuming immutable verified artifacts; untrusted PR/fork code and ordinary compile/test scripts receive no signing key. - [ ] Pass secrets through a reviewed non-logging channel to the narrow signer, scrub owned temporary material on success/failure/cancellation and exclude it from caches, dumps, job logs and uploaded artifacts. Verify secret absence without printing/search-reporting its actual bytes. - [ ] Preserve boot-tool's detached payload/signature/verification contract; record public key fingerprint, exact signing payload/artifact hashes, source graph and signing policy without exposing private credentials. - [ ] Publish an explicitly named signed `boot.img` plus verification material/provenance per profile/key cohort, and ensure every downloadable disk contains its corresponding exact tested signed payload and rootfs authority closure; verify downloaded bytes independently of local publisher status. Protected CI re-signing/repackaging creates a separately verified/tested cohort, not a byte-identical [integration#9](https://git.erikinkinen.fi/erix/integration/issues/9) result or permission for hidden host build completion. - [ ] Test protected signing success, missing/wrong secret, untrusted-ref denial, modified input, signer failure and cancellation; publication must stop on failure and no unsigned/test-key output may be mislabeled trusted. - [ ] Implement full supported-platform UEFI Secure Boot packaging with a custom EriX/user-controlled certificate: sign the PE/COFF EFI loader in the firmware-required format and keep its verification material consistent with boot/rootfs trust. An Ed25519 boot.img signature is not firmware EFI signing. - [ ] Provide documented custom PK/KEK/db/dbx enrollment, owner-authorized updates, certificate distribution and revocation/recovery procedures without dependence on a Microsoft signature. Back up existing enrollment and require explicit approval before changing real firmware variables or owner keys. - [ ] Define enforced versus explicitly non-enforced development boot modes and check SecureBoot/SetupMode state where appropriate; never report successful enforcement while firmware is in setup mode or validation is off. - [ ] Add QEMU/OVMF Secure Boot fixtures with private firmware-variable storage and custom enrollment; prove correct-key boot and refusal of unsigned, wrong-key, tampered and revoked EFI images without a permissive fallback path. - [ ] Exercise the full enforced chain with tampered boot.img, rootfs policies, executables and shared libraries; firmware success alone cannot close downstream verification gates. Include both clean and extended profiles. - [ ] Test key rotation/revocation, interrupted updates and documented recovery using independent fixtures, preserving least authority and a usable owner recovery path rather than silently disabling verification. - [ ] Perform a manually approved real-firmware enrollment/boot/rejection validation on the supported hardware baseline; record firmware versions and limitations. OVMF evidence alone is not a claim of universal firmware support. - [ ] Audit signing/verification code and CI boundaries independently, update threat models/rustdoc/man/manual and include malformed crypto/container inputs without introducing third-party code into clean-room components. - [ ] Verify normal signed loading does not retain signer/admin authority in loaders or applications; profile verification overhead through [integration#3](https://git.erikinkinen.fi/erix/integration/issues/3) and optimize only exact immutable identities with sound invalidation. - [ ] Include signing/trust tests in the full CI and both [integration#9](https://git.erikinkinen.fi/erix/integration/issues/9) build generations, using scoped development keys for self-host proof and protected CI signing for downloadable outputs; document the distinct trust policies. - [ ] Produce an operator verification/enrollment/recovery runbook and alpha-review evidence showing the exact EFI→boot→rootfs trust chain, public verification keys and download hashes, with no private signing material. - [ ] Design/version a distinct **unsigned user-preference section in `boot.img`**, separate from signed executable/configuration/authority data. Whitelist non-authoritative typed settings, initially keyboard-layout ID; preferences cannot select trust roots, bypass verification, choose executables, alter capability/realm policy or grant device/namespace access. - [ ] Authenticate the container format and section directory/bounds, including the precise permitted unsigned extent. Exclude only that preference payload from the boot signature's authenticated message; verify every security- relevant byte and reject overlap, aliasing, truncation, confused versions and attempts to reinterpret signed bytes as preferences. Give the preference descriptor an authenticated explicit hash policy: no signed section hash may still depend on mutable preference bytes. Any optional corruption checksum for those bytes lives inside their unsigned extent. - [ ] Implement build/read/update tooling for preferences without private signing authority, preserving all authenticated bytes, section extents and signatures. Record separate full-container digest and signed-content identity: preference edits change the former, not the latter; refresh local artifact receipts without falsely claiming an edited image matches published checksums. Coordinate any outer boot-image/catalog authentication so it anchors signed core identity, not a whole-file digest that silently forbids unsigned edits; retain whole-file digests as exact distribution/integrity evidence. - [ ] Parse preferences as bounded untrusted input with deterministic absent/malformed/unsupported-value handling, defaulting keyboard layout to `en_US`. Malformed preference content may fall back, but malformed authenticated structure or signature failure must still fail closed, never enter fallback. - [ ] Carry the validated preference value to its consumers as explicitly non-authoritative data, distinct from trusted clear-completion and authority handoff fields. Only select packaged, signed, allowlisted keyboard definitions; preference text cannot load a script, plugin, arbitrary path or mapping code. - [ ] Add signature/container unit tests and VMs showing layout-only preference edits preserve Secure Boot/boot-content verification, while changing signed code, policy, bounds, key selection or verification flags is rejected. Test integer overflow, unknown/duplicate keys, padding and recovery defaults. - [ ] Version boot-image/handoff parsing and every consumer's trust classification for unsigned preferences; do not reuse `MUTABLE_AFTER_BOOT` or descriptors promising all bytes were signature-verified as an unsigned bypass. Update format/coverage vectors, boot-tool/manual docs and negative version tests together, then retire superseded intake under [integration#2](https://git.erikinkinen.fi/erix/integration/issues/2) without a permissive fallback. - [ ] Keep the optional boot-logo bitmap and its type/dimensions/format under signed boot-image coverage, separate from unsigned user preferences; decode/render it only after authentication. Logo substitution cannot extend the unsigned region, select executable content or alter authority handoff. 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 Bare digests and successful firmware boot are insufficient for downstream signed coverage; anti-rollback also needs a real trusted version anchor. Protected CI re-signing is a separately verified cohort and cannot conceal a host build step in the two-generation proof. Original realm image UEFI prerequisite — 18 September 2026: Signed `acc1e734f79366e965b7ab7cd41496afddc6b1fe` adopts the original dynamic-link contract dependency. Four default/all-feature development/release Rust configurations, four UEFI builds with fatal linker warnings, strict host/UEFI Clippy, formatting and private rustdoc pass. All 53 Python fixture controls and the explicit signing authority checks pass. The emitted console debug EFI/PDB association and release artifact tree pass inspection with zero warnings. Direct implementation bytes are unchanged. Original CI must still accept both exact source-pair profiles and deliberate release diagnostics; coherent image and full guest-build acceptance remain separate requirements. Original coherent realm source CI acceptance — 18 September 2026: Signed `acc1e734f79366e965b7ab7cd41496afddc6b1fe` passes [CI 142](https://git.erikinkinen.fi/erix/bootloader/actions/runs/142) and [CI 141](https://git.erikinkinen.fi/erix/bootloader/actions/runs/141). All four terminal logs are complete (144,166 bytes), with zero final warnings. This closes the original CI observation recorded above. Coherent catalog publication, actual consumer VMs and full guest-build acceptance remain separate open requirements. ## Tracking and rollout ### Command and boot dependency alignment — 15 September 2026 Signed `d48450b6bbccc80cbae3cfcf2feece3e6b04a347` aligns the existing dependency selections with the original signed runtime graph. This checkpoint changes Cargo selections and the roadmap; this repository's Rust implementation files are unchanged. Formatting, strict Clippy, private rustdoc and canonical documentation checks pass without warnings. Default/all-feature development/release tests pass 41 default / 41 all-feature tests. All four host and UEFI configurations build successfully, including the supported make entry point. Signing-authority checks and 53 source/artifact/profile-owner fixture tests pass, as does private build-script documentation. The exact committed source-pair reproducibility, default/console EFI/PDB profiles and deliberate release-diagnostic checks pass in both component CI runs. Push/review CI 139/140 passes with complete classified logs and no final warnings. The product catalog, product VM acceptance and guest build remain pending. Review: https://git.erikinkinen.fi/erix/bootloader/pulls/3. 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

docs

phase-6

enhancement

ci

labels 2026-09-12 07:56:24 +02:00

erikinkinen referenced this issue from erix/ttyd 2026-09-12 07:56:25 +02:00

[FEATURE] Complete independent consoles, vttys, TUI, keyboard layouts, mouse and boot logo #1

erikinkinen referenced this issue from erix/integration 2026-09-12 07:56:29 +02:00

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

erikinkinen referenced this issue from erix/integration 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 from erix/integration 2026-09-12 07:56:30 +02:00

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

erikinkinen referenced this issue from erix/integration 2026-09-12 07:56:30 +02:00

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

erikinkinen changed title from [FEATURE] [P20] Enforce firmware-to-rootfs signatures and scoped signing of build outputs to [FEATURE] Enforce firmware-to-rootfs signatures and scoped signing of build outputs 2026-09-12 08:02:03 +02:00

erikinkinen referenced this issue 2026-09-12 18:08:39 +02:00

WIP: Preserve boot artifact and native entry contracts #3

erikinkinen referenced this issue from erix/integration 2026-09-19 11:36:52 +02:00

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

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

feature/posix-compat

feature/native-cli

feature/phase-4-audit

feature/dynlink

feature/e2fs-fat

feature/block-devices

feature/centralized-process-authority

No results found.

Labels

Clear labels

  

bug

Something is not working

  

ci

  

docs

  

duplicate

This issue or pull request already exists

  

enhancement

New feature

  

help wanted

Need some help

  

invalid

Something is wrong

  

performance

Measured performance profiling, bottleneck analysis, and regression budgets.

  

phase-6

Phase 6: POSIX compatibility, full EriX self-hosting, and its required audits and validation.

  

question

More information is needed

  

refactor

Code cleanup, removal of obsolete paths, and structural improvements preserving behavior.

  

security

  

wontfix

This won't be fixed

No labels

bug

ci

docs

duplicate

enhancement

help wanted

invalid

performance

phase-6

question

refactor

security

wontfix

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

erix/bootloader#1

No description provided.