Repository navigation
v0.12 T04 blocker: isolated restore and crash-recoverable lock/restore transactions #71
Description
Status
Blocks promotion of T04 hardening PR #70 and progression to T05. Current T04 source is on fix/v0.12-t04-state-engine-hardening, and the cumulative main-targeted PR #69 must not be merged independently.
Remaining independent-review findings (risk 3)
- P1: Restore staging is not isolated against a hostile process running under the same local UID. A process can replace a directory within the stage between a path preflight and
openSync()and redirect writes outside the project. See fix(v0.12 T04): crash-safe event append, process locks and restore confinement #70 (comment). Node.js pathname APIs alone do not provide cross-platform descriptor-relative unreplaceable traversal. Do not claim protection from arbitrary same-UID attackers without OS-native handle APIs or process isolation. - P2: Non-atomic two-rename root promotion can strand the complete target root after a crash. See fix(v0.12 T04): crash-safe event append, process locks and restore confinement #70 (comment).
- P2: Reclamation mutex
.state.lock.reclaimcan be orphaned if its owner crashes, blocking later state writes until safe manual intervention. See fix(v0.12 T04): crash-safe event append, process locks and restore confinement #70 (comment).
Required architecture decision
Select an explicit supported security boundary before implementing further patches: (A) an isolated recovery helper with native directory-handle-relative APIs and appropriate OS credentials, or (B) a restricted offline restoration feature that fails closed outside a trusted, exclusively controlled recovery workspace. An unverified boolean/trust flag or directory permission 0700 is not sufficient against a same-UID attacker.
Acceptance contract
- All backup writes remain inside the intended root under injected parent swaps, hardlinks, junctions and symlinks. Include deterministic swap-at-open and swap-at-rename tests on supported platforms.
- A crash at every transaction boundary can be resumed/rolled back deterministically without discarding the original root, with a durable journal and startup/manual recovery before any new restore.
- Lock guard crash cannot leave the system permanently blocked without a documented, verified, safe recovery path. An explicit fail-closed maintenance procedure is permissible only if the limitation is accepted in the T04 contract.
- Restore does not silently change original root mode, ownership, traversal ability or custom ACLs; for unsupported host metadata semantics, fail closed and document the limitation.
- The existing H01–H23 security/concurrency tests and the complete Ubuntu/Windows
npm run release:validatematrix must pass twice on the same reviewed HEAD. No skipped supported security fixture. - Independent code, architecture, and security reviews must report zero unresolved Critical/Major findings and the deterministic risk-3 acceptance evidence must be persisted in
.development-kitgovernance before merge.
Non-goals / exclusions
No T05–T10 functionality, package version release, registry changes or deletion of retained legacy state. This issue does not authorize an npm/GitHub release.
Activity
eybersjp commentedon Oct 9, 2026
T04 recovery design — proposed closure evidence (independent approval pending)
Selected Issue #71 option B: restricted operator-controlled offline restoration, without claiming portable Node.js can defend against hostile same-UID filesystem mutation. Restores now fail closed unless the caller explicitly sets
confirmOffline: true. This is a required operational attestation and no guarantee of actual OS isolation; use is unsupported when co-tenant processes can manipulate the project or sibling stage. Seedocs/04-architecture/dkf-state-engine-v2-offline-recovery-boundary.md.Implemented a durable sibling journal with precise stage/root device/inode witnesses encoded as BigInt decimal strings, explicit
recoverLegacyRestore({targetRoot,confirmOffline:true}), file/directory sync and interruption recovery. H25 and H28 exercise exception and real child-process termination between the two root renames. New restores refuse to run while an incomplete journal remains.Implemented owner metadata and conservative explicit
recoverAbandonedStateLock({rootDir,confirmOffline:true}). It verifies a 60s-old guard and a dead local PID; H26/H27 cover orphan and live-owner denial. Normal writers never remove uncertain guards.Previous code SHA
223982fb7ee5...passed full Ubuntu/Windows CI run 37972680014 with H01–H28. Latest source includes additional staged-tree syncing and a Windows write-handle correction; latest exact-source CI and independent risk-3 review are running. Issue remains open until independent reviewers confirm acceptable scope, no in-scope Critical/Major findings, and deterministic T04 acceptance is persisted.eybersjp commentedon Oct 12, 2026
T04 status — exact source
cf0fd8208cd262da29dfe0d91576c4808efa6873Verified final CI matrix on GitHub Actions run https://github.com/eybersjp/development-kit/actions/runs/38318331981:
validate (ubuntu-latest)SUCCESSvalidate (windows-latest)SUCCESST04 independently reviewed acceptanceFAILURE: evidence is still pending, not a source/test validation pass.The Ubuntu job's decoded log records T04-H43, H44 and H45 PASS, with 66 passing / 1 skipped in its focused suite (the skipped case is Windows-only H14). Local Windows validation was reported as 56 passed / 11 skipped, with the skip rationale recorded in
docs/04-architecture/dkf-state-engine-v2-t04-hardening-validation.md. These platform-conditional skips are not interchangeable with cross-platform assurance.Three independent, single-role, exact-source review requests are queued on PR #70:
As inspected, each request has only a Codex
eyesacknowledgement; no authentic+1clean review or source-bound accepted review receipt exists.docs/04-architecture/dkf-t04-independent-review-receipts.jsonstill hasreviewedCommit:null,reviews:[].Human security/PO decision still required: the separate proposal to limit automatic runtime protection to a trusted/exclusive local environment (excluding hostile same-UID mutation) is explicitly a candidate and cannot be adopted on assistant authority or inferred from the previously chosen offline restore Option B. The author must explicitly accept or reject this narrower runtime contract with its limitations before T04 risk-3 approval.
Keep Issue #71 and PR #70 open, no T05 progression/merge, until the three authenticated independent reviews, explicit scope decision, zero unresolved Major/Critical findings, and deterministic T04 ACCEPTED record all exist.
eybersjp commentedon Oct 12, 2026
Product Owner disposition — defer stronger runtime isolation
The Product Owner's latest direction is to leave hostile concurrent same-account filesystem protection for a later Development Kit revision, and mark it for explicit reconsideration. Tracked in Issue #72: #72.
For v0.12.0, treat the documented trusted, exclusively controlled local runtime as the chosen limited supported operating environment for T04. Do not claim portable Node.js prevents a hostile same-UID process from swapping canonical event ledgers or recovery journal entries. The prior restricted offline restoration (Issue #71 option B) is separate and unchanged. This scopes the unsupported adversary case; it does not establish an atomic filesystem guarantee.
T04 independent gate remains mandatory: confirm v0.12 scope disclosure and requirements, zero remaining in-scope Critical/Major defects, valid exact-source code/architecture/security reviews, Windows+Ubuntu validation, authentic receipts and deterministic
ACCEPTED. Don't treat this decision as an external review approval; do not invent receipts or merge before those independent gates pass.No need to repeatedly ask for this same scope choice during v0.12 unless the implementation reveals a materially different risk or incompatibility. Future version planning must reopen Issue #72.
eybersjp commentedon Oct 12, 2026
DKF v0.12.0 continuation — T04 implementation and review status
As of exact PR #70 head
c04615700476cd55c57d3eea58026ac91bda1107, the latest full-source corrective round includes:MoveFileExW(MOVEFILE_WRITE_THROUGH)offline rollback helper; H48 passed twice in Windows GitHub Actions run https://github.com/eybersjp/development-kit/actions/runs/38321401970, which passed Windows and Ubuntu validation. Documentation explicitly does NOT overclaim full power-loss durability.Remaining blockers: Issue #73 Windows native durable rollback and normal staged promotion/journal ordering needs independent verification/architecture closure; PR #70 has three unresolved review threads until current-head review. Exact-source authentic role receipts and deterministic
ACCEPTEDare still absent. The separately approved same-account attacker deferral Issue #72 does not waive Issue #73 or the risk-3 gate.The approved plan explicitly prohibits commencing T05 Lifecycle Instances until T04 reaches deterministic ACCEPTED; T06–T10 depend sequentially thereafter. PR #70 has NOT been merged into its T04 base, PR #69 has NOT been merged to main, and v0.12.0 has NOT been released. The hourly DKF v0.12 completion workflow is configured to continue at the next lawful gate and surface substantive decisions/findings.