Skip to content

Make the harvested verifiedBootHash user-editable; honour pinned NDK in build.sh - #312

Merged
JingMatrix merged 1 commit into
JingMatrix:devfrom
cawilliamson:harvest-hash-override
Oct 19, 2026
Merged

JingMatrix merged 1 commit into
JingMatrix:devfrom
cawilliamson:harvest-hash-override

Conversation

@cawilliamson

Copy link
Copy Markdown
Contributor

Two independent fixes; separate commits, feel free to cherry-pick.

1. verifiedBootHash is now user-editable (84dcb99)

On devices where the TEE reports a usable-but-useless boot hash (unlocked bootloader with verification disabled reports an all-f placeholder), there was no way to override the hash: userEditable only allowed it when the captured value was a fallback, and buildOverrides emitted no entry at all when the raw capture was usable — so the WebUI showed the field locked and overrides.json entries were ignored (override ignoring non-editable field 'verifiedBootHash').

Since the hash is attestation-only and — per the existing docs — carries no stored-key/KEK constraint (unlike the boot key, which stays fallback-only-editable), it is safe to always present it as an editable override:

  • buildOverrides now always emits a verifiedBootHash entry; when the raw capture is usable it presents the captured value as the replaceable default
  • userEditable needs no change: it already keys off the entry's editable flag
  • the WebUI needs no change: the row is rendered from the status meta and verifiedBootHash is already in the field order/hex-editor lists

Verified on device (unlocked OB-A98, GSI): override in overrides.json now applies, the daemon force-syncs ro.boot.vbmeta.digest to the attested value, and fresh attestations carry the configured hash.

2. build.sh: honour an explicitly pinned NDK (2426f88)

rust/build.sh only honoured NDK_HOME, then fell back to newest-installed-wins — silently overriding the workflow's deliberate ANDROID_NDK_HOME pin ("Pinned for reproducibility") whenever the runner image ships a newer NDK. Current ubuntu-latest images now include NDK 30 alongside the pinned 28.2, and the openssl-sys bindgen step fails against NDK 30 (Unversioned target triples are not supported!) — dev-branch CI is affected too. The fallback now prefers ANDROID_NDK_HOME when it points at a real directory.

Both changes covered by the normal zipRelease CI run on my fork (green on harvest-hash-override).

the data-dir FileObserver only matched config.json and *.xml, so a save
from the overrides group wrote overrides.json but resolveAndPush() never
re-merged and /status kept serving the boot-time record -- an override
edit appeared to revert to the stale value until the daemon restarted.

overrides.json is written atomically like config.json (temp file +
rename), so the existing CLOSE_WRITE/MOVED_TO mask already covers it;
only the path filter needed widening.
@JingMatrix
JingMatrix force-pushed the harvest-hash-override branch from d3c57ea to b78b93a Compare October 19, 2026 15:44
@JingMatrix

Copy link
Copy Markdown
Owner

Thanks — d3c57ea is the one I want even on its own: writeOverride() in system-controller.js waits 600 ms for the DATA_DIR watcher and never calls /rescan, while OverrideStore.load() is read only from the daemon's init and resolveAndPush, so as things stand a WebUI override edit does nothing until a reboot or some unrelated push.

@JingMatrix
JingMatrix merged commit 5148321 into JingMatrix:dev Oct 19, 2026
1 check passed
JingMatrix added a commit that referenced this pull request Oct 19, 2026
The DATA_DIR observer fired only for config.json and the keyboxes, so an override written from the
WebUI reached nobody: writeOverride waits 600ms for that watcher and never calls /rescan, and
OverrideStore.load runs only at daemon init and inside resolveAndPush. An edit therefore did
nothing until a reboot or an unrelated push, while /status kept serving the pre-edit record.

Co-Authored-By: JingMatrix <jingmatrix@gmail.com>
@JingMatrix

Copy link
Copy Markdown
Owner

@cawilliamson Can you please again a new PR with commit cb4044a.

The first merge has formatting issue, while the second merge we have the annoying unverified status.

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.

2 participants