ci: optimize emulator build context - #7
Closed
BitHighlander wants to merge 1 commit into
Closed
Conversation
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
BitHighlander
force-pushed
the
hotfix/emulator-ci
branch
from
March 5, 2026 19:51
26e34ba to
6487773
Compare
BitHighlander
added a commit
that referenced
this pull request
Mar 29, 2026
PR #7-prep: EVM blind-sign hard gate
5 tasks
BitHighlander
added a commit
that referenced
this pull request
Aug 12, 2026
…st one The roadmap read as a settled architecture with open parameters. It is not: seven of its foundations are undecided, six of them change what a ROM measurement would even be measuring, and one -- custody -- is not decidable in a document at all. A new §0 states that up front, with an ordering, because the expensive mistake here is costing a validator against a substrate nobody has chosen. Resolved in the text: #8 One canonical certificate. §5b and §6 described the same signed object with different fields, and the acceptance rule then tested "epoch within [epoch_min, epoch_max]" against an `epoch` field that appeared in neither. Three descriptions of one signed object is three implementations of one trust boundary. `bitcoin_not_before/not_after` are gone (anchor + delta said it already, in a form that invites reading it as a clock); the range is gone (a certificate has one epoch). Phase 1's "built-in anchor" and Phase 2's "pin the root" stop contradicting each other once they are named as what they are: a SCHEMA root and a DELEGATION root, separate keys with separate ceremonies -- which also lets Phase 1 proceed while custody is open. #1 "clearsign_freshness absent or inert" in bitcoin-only meant full -> bitcoin-only -> full resurrected every expired delegate, and contradicted the shared substrate two paragraphs above it. Now: carried opaquely, unable to advance or lower, with the alternative (full firmware refusing to clear-sign when freshness cannot be established) stated explicitly, because the default behaviour of a missing field is to read as zero and accept everything. #6 BitcoinFreshnessBegin no longer carries the anchor or the thresholds. A host that supplies the values deciding whether its own proof passes picks an anchor it can cheaply extend; it may reference a certificate the device has already verified, and stream headers. Plus rate-limited advances -- an attacker needs no forgery, only genuine chains replayed ever longer, one flash commit each. Specified, with the remaining choice named: #2 The four-field SecurityRatchets facility does not exist. The anti-rollback RFC reserves ONE OTP block as a 256-step unary counter, which cannot hold a block height, and authenticated flash stops forgery but not restoration of an authenticated older snapshot. Required shape: OTP-backed coarse generation plus an authenticated journal bound to that generation -- with rollback tolerance, checkpoint granularity, wear budget and power-loss state machine as four decisions, not details. #3 "ROOT SIGNATURE -> firmware_epoch, storage_epoch, clearsign_epoch" reads as one key over all three, reintroducing one level up the concentration §3 rejects. Named roots per ratchet, cryptographic separation, and cross-protocol replay as a release gate. #4 The RFC requires rejecting a low-epoch candidate BEFORE erasing, and old-or-new bootability after power loss. handler_erase() in tools/bootloader/usb_flash.c:425-493 erases sectors 7-11 on FirmwareErase, before any candidate bytes exist, with one application slot. Three ways out, one of which is to admit the recovery-only state in writing -- today's honest description, and still a choice that has to be made rather than inherited. #7 The blind-sign policy is security-critical persistent state with no integrity protection specified. In today's public storage section a physical attacker flips one bit and enables the downgrade policy directly, silently, without touching a certificate. Authenticated storage or a session-scoped model, plus stated behaviour after reset, after a variant change, and on corruption -- fail closed each time. Left for an owner: #5 Single-root custody. One dice-generated key on one KeepKey, holding the one privilege §6 grants -- warning-free rendering. N-of-M across independent devices and locations, with rotation, backup, disaster recovery and an overlapping-anchor transition. Phase 2 is gated on it: a root in shipped firmware cannot be un-shipped. §9 keeps the genuine parameters and says plainly that they sit downstream, and Phase 3's release gates gain one negative test per blocker.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
.dockerignoreto exclude CI configs, docs, and markdown from Docker build context (faster builds)versionkey fromdocker-compose.ymlTest plan
emulator-build-testpasses (emulator builds + python-keepkey tests + firmware unit tests)🤖 Generated with Claude Code