Skip to content

The ESP's records reach a terminal and update.log only in the shape Kryptik writes them - #234

Merged
DevomB merged 1 commit into
mainfrom
esp-records
Oct 7, 2026
Merged

DevomB merged 1 commit into
mainfrom
esp-records

Conversation

@DevomB

@DevomB DevomB commented Oct 7, 2026 •

Copy link
Copy Markdown
Owner

The ESP is plain FAT, and only its kernels are signed. Its records (kryptik/committed-slot, kryptik/version-a, kryptik/version-b) were printed as found: kryptik-update status (lines 103 and 105), the slot's version that kryptik-update rollback writes to update.log and the terminal, kryptik-recover --status and its commit message, and the medium's install verify line. Whoever held the disk could rewrite them to carry terminal control sequences onto root's screen, or to make status name a version that is not there.

What changed: build/service-scripts/esp-records.sh is the one reader for all of them.

  • esp_slot FILE [ABSENT] prints a or b.
  • esp_version FILE [ABSENT] prints a version in the shape the release flow produces: MAJOR.MINOR.PATCH without leading zeros, as build/lib/release-keys.sh numbers a release, optionally followed by a development build's parts, such as 0.1.20261007.1a2b3c4d.1 from stage 06 and the Distro workflow.
  • Each reads at most a bounded first line and prints unknown for anything else. A missing record prints what the caller asks (none where status said so before).

kryptik-update sources the reader with devices.sh; kryptik-recover and installer-run.sh source it at the top; boot-check lists it. boot-success.sh is untouched: its read of committed-slot is only compared, and #226 already narrows it to a, b or nothing.

How it is proven: the new tools/tests/esp-records.sh covers each shape: releases and development builds taken; terminal sequences, words after a version, a version on the second line, overlong, empty and absent records refused. tools/tests/update-esp.sh runs the tool's own cmd_status on rewritten records and expects unknown and no escape byte in its output. The Distro run's update suite reads kryptik-update status ("committed slot: b") and passes through every rollback and recovery. Locally the new fixture passes 21 of 22: Git for Windows' sed strips the carriage return in one case, which sed on Linux keeps.

Distro run 37571834362 at b756538: every part green (install, update, integrity and zones, inputs, boot, desktop, production update-test 27/0) except build/host-suites, whose one failing check is tools/tests/glibc-branch-patch.sh; #233 fixes that on main, and this branch predates it. Taken on that basis by the integrator. CI green.

…ryptik writes them: kryptik-update status and rollback and kryptik-recover printed committed-slot and version-a/b as found, so whoever held the disk could put terminal sequences on root's screen or a false version in status

build/service-scripts/esp-records.sh reads them for every tool that shows them: esp_slot gives a or b, esp_version a release's version (MAJOR.MINOR.PATCH as release-keys.sh numbers a release, then a development build's dated parts), each from a bounded first line, and unknown otherwise; a missing record reads as the caller says. kryptik-update status and rollback, kryptik-recover --status and its commit message, and the medium's install verify line use them; boot-check lists the file. boot-success's read of committed-slot is left as #226 has it, a or b or nothing.

tools/tests/esp-records.sh covers the shapes (terminal sequences, words after a version, a second line, overlong, empty, absent); tools/tests/update-esp.sh runs the tool's own cmd_status on rewritten records.
@DevomB
DevomB marked this pull request as ready for review October 7, 2026 07:27
@DevomB
DevomB merged commit 5d84f16 into main Oct 7, 2026
19 of 21 checks passed
@DevomB
DevomB deleted the esp-records branch October 7, 2026 08:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant