Skip to content

UP-01: Validate version, source, channel and content #107

Closed

Description

@andersalm

Part of #89.

Owner: Anders (@andersalm).

Task base and PR target: develop, approved by Anders; current fetched base is de1db928. Anders approved starting this task while the predecessor PR is in review. Final integration must include any required predecessor changes.

Depends on UP-00 (#106).

Done means

Release acceptance: Each exposed feature works clearly from start to end, including recovery. Keep unfinished or confusing features hidden until their complete journey passes. Hiding a feature does not complete its task; source checks alone do not establish installed acceptance.

  • Shared CLI/operator logic compares exact parsed versions and rejects accidental downgrade or replay.
  • The selected source and subscribed channel match the signed release.
  • Fetch uses the requested CID rather than call order, verifies those bytes, and distinguishes head CID from release CID.
  • Negative tests cover malformed/prerelease versions, wrong channel, wrong content and an explicit older-CID request. Supported legacy publisher/client behavior is tested.
  • The updater installs the verified artifact bytes unchanged, including components.json through support-asset refresh. The installed SHA-256 matches the verified artifact; a parsed-content comparison is diagnostic only and never replaces the byte check. Keep required local metadata separate.

Activity

  1. added this to the 0.7.1 milestone on Sep 29, 2026
  2. self-assigned this
    on Sep 29, 2026
  3. andersalm commented on Sep 29, 2026

    @andersalm
    ContributorAuthor

    Retained compatibility checks: version parsing must distinguish rc.1 from rc.10; channel selection must use the matching publisher endpoint. Inspect CID forms actually used by supported publishers before choosing a verifier. The earlier raw-CID-only proposal was an option, not established compatibility.

  4. andersalm commented on Sep 29, 2026

    @andersalm
    ContributorAuthor

    UP-01 is the next open Signed update task after #106 closed. Its dependency is satisfied by the UP-00 diagnostic receipts and PR #79 at a38015e4.

    Work boundary before implementation: #107 owns shared CLI/operator version, source, channel and CID validation with rejection and supported legacy tests. It does not own staging, restart, Undo, UI or release publication. The existing Mac fixture approval covered the UP-00 observation. Any new real signed apply or change to that retained fixture needs a separate exact test scope; source and isolated test work can proceed after the work-branch base is selected. User Homes and seed state remain outside the test.

    After git fetch origin --prune, the available development base is origin/upstream/0.7.1-dev at 6c61c990. Existing working branches include origin/feat/0.7.1-models at e80269ce and origin/feat/0.7.1-update-hop at a38015e4. The repo workflow requires Anders to choose the base for a new feat/* or fix/* branch. A working-branch base would make #107 depend on that parent for merge order and would need a rebase if the parent moves. Branch creation and implementation wait for that choice. No UP-01 test or code change has started.

  5. andersalm commented on Sep 29, 2026

    @andersalm
    ContributorAuthor

    Read-only UP-01 source findings on origin/feat/0.7.1-models at e80269cefb63626f4db8cff82d7d972f3d48b502 (tree 75c00b82605452f2759f0fabe31b3e802fba2c33). No branch, code edit or fixture run was made.

    • Shared updater admits a release when its version string differs from the installed string. Operator check uses the same inequality. This leaves rc.1 versus rc.10, malformed versions and accidental downgrade/replay to a shared parsed-version rule. The existing release binding checks head/release version and channel agreement, but the subscribed TrustedSource.channel is not part of that admission check. Small tests belong at this shared boundary for exact version order, malformed/prerelease inputs and source-channel mismatch.
    • The CLI fetch adapter and operator fetch adapter ignore the requested CID and select release-head.json, release.json, binary and components by call count. The Carrier announcement also fills head_cid from latest_release_cid, which names the release. Existing shared tests verify the signed release SHA binding, but they do not prove that an explicit older head CID fetched those exact bytes. The narrow regression is an older-CID request plus a mismatched returned object for each adapter, with head and release CID identities kept distinct.
    • Publisher compatibility needs the CID verifier to accept the forms the supported publisher emits. Publication obtains installer CIDs through ipfs-provider add_path; that provider calls Kubo add with its default options. The signed release_object_cid is a separate content-object identity. The earlier raw-CID-only idea is therefore not an established compatibility rule. A fixture test should bind the actual publisher output CID to the fetched file bytes, including supported legacy output, before a verifier is fixed.
  6. andersalm commented on Sep 29, 2026

    @andersalm
    ContributorAuthor

    Additional bounded compatibility finding on the same models source e80269ce:

    The updater treats two older publication fields differently. release_object_cid is optional, so a signed head without the newer content-object sidecar can proceed. release_sha256 is required, and the existing binding test expects a missing digest to fail. Current publication writes both fields. Before the #107 legacy test is finalized, record which older signed-head shape remains supported: absent sidecar is already handled; absent release SHA currently has an explicit rejection. This keeps the legacy acceptance test tied to the real publisher/client contract instead of treating every old shape as accepted.

    No test or build was run in this read-only pass.

  7. andersalm commented on Sep 29, 2026

    @andersalm
    ContributorAuthor

    Starting implementation from the fetched feat/0.7.1-models base, as Anders approved. The worker will record its exact branch and commit here. Keep one In progress task in this lane. Reuse the existing source findings, share the single heavy local build slot, and keep status and proof in this issue. The predecessor stays in QA / Review until reviewed and merged.

  8. andersalm commented on Sep 29, 2026

    @andersalm
    ContributorAuthor

    UP-01 implementation started on local branch fix/0.7.1-update-validation from freshly fetched origin/feat/0.7.1-models at b1a22a6ec0c0aed2a8df44cc4cdf98618eadd61b (tree 05f614b7b4941bdddbd0d8306dc32b6e9b5e8fd3). The checkout was clean at creation. PR #79 remains on its own branch at a38015e4 and is in human review; this branch imports no PR #79 commit. The earlier read-only findings used models at e80269ce; relevant updater files will be checked against this exact base before edits. No new Mac fixture run or heavy build has started.

  9. andersalm commented on Sep 29, 2026

    @andersalm
    ContributorAuthor

    UP-01 is in draft PR #132: #132

    Commit 174f4f8c is based on fetched feat/0.7.1-models at b1a22a6e. The pushed task branch and origin/fix/0.7.1-update-validation are even. The source change binds CLI and operator update checks to parsed SemVer, the selected source channel, and the requested head and release CIDs. The publisher now announces the recorded head CID separately from the release CID.

    Mac source proof passed: 18 focused update::tests, the Carrier announcement test, the existing Carrier CID provider fetch test, git diff --check, Home entropy, workspace format, and chain-provider format. The negative tests cover malformed and prerelease versions, downgrade, wrong channel, changed metadata, an explicit older head CID, and wrong binary bytes. Legacy tests cover the stable default channel, CIDv0 Kubo metadata, and signed heads without release_object_cid; release_sha256 remains required.

    The remaining acceptance gate is integration with reviewed PR #79 and installed behavior from the approved isolated fixture. The issue stays open while that evidence and PR review are pending.

  10. andersalm commented on Sep 29, 2026

    @andersalm
    ContributorAuthor

    I fetched origin/feat/0.7.1-models at 77c83c56dd13fdbdca65db37232114cbd9883a6c (tree 3b5ec0c43569027fd40f680f35350bda5888f5f6) and read its complete merged AGENTS.md after PR #127. I acknowledge that this policy now governs UP-01. Draft PR #132 and the task branch keep their current history; this policy check changed no source or Git history. I will use the issue proof, review and merge gate, approved target, and one-heavy-Mac-build rule for the next work step.

  11. 13 remaining items

  12. andersalm commented on Sep 30, 2026

    @andersalm
    ContributorAuthor

    The second installed attempt verified that CLI Check and Apply both reject the signed older release with artifact and fixture-data hashes unchanged.
    Operator Check stopped at command validation because the private controller omitted its explicit --check flag. Its corrected invocation now uses that flag; Apply already uses --apply --yes.
    The second receipt is retained. Every owned process stopped and all fixture locks released; the candidate and prepared artifact bytes are unchanged. The next run repeats the full matrix before applying the valid release.

  13. andersalm commented on Sep 30, 2026

    @andersalm
    ContributorAuthor

    The third run passed CLI and operator downgrade refusals and CLI wrong-channel refusals, with artifact and fixture-data hashes unchanged.
    Operator wrong-channel Check also refused. Its public error reports failed trusted-source discovery, while the controller expected the inner channel error. The next run pairs successful valid-release Checks with the negative matrix and recognizes that exact refusal.
    The retained receipt records this diagnostic wording limit. All owned processes stopped and locks released; source and artifact hashes remain unchanged.

  14. andersalm commented on Sep 30, 2026

    @andersalm
    ContributorAuthor

    Installed proof for 476587230798e8418dfdc60730384ddacfbc5d5c / tree 393b549aa8b3a25f23c9d7257b37e23d2b75cebc used two version-stamped native Mac binaries from that exact source.
    Both CLI and operator Check/Apply rejected signed older and wrong-channel releases; all eight refusals preserved installed bytes and fixture data. CLI also rejected an explicitly selected older head while a newer head was announced.
    CLI Apply succeeded over Carrier/IPFS, refreshed the changed support asset, and preserved published manifest SHA-256 c9ee834e6934d5cfbe6b25f60fcc891eb341c9289512c7fb2dfa00ad8b7fc38e at the installed path.
    Operator Apply verified both downloads and replaced the binary, then its host exited 75 before the manifest write. The manifest and source version stayed old; this run never reached support refresh.
    The new binary SHA-256 is 2041b4b021ed473330bc7cdbe8007a8bba9ee00e2ecb0f3730e784dd5a9ddace; the retained receipt binds both inputs, providers, publication, refusals and exact process exits.
    All owned processes stopped and host locks released. Ordinary CLI recovery after this interrupted operator update is next; automatic restart and complete operator Apply remain unproven.
    Candidate CI is separate evidence. #107 stays open; the shared-source fixture does not establish cross-version migration or catalogue replacement.

  15. andersalm commented on Sep 30, 2026

    @andersalm
    ContributorAuthor

    Recovery proof on 47658723 completed: after the interrupted operator host exited, ordinary local elastos update --yes returned 0 and advanced its source to 0.7.1-up01.2.
    Both fixture Homes then started explicitly, passed their health and host-lock checks, retained the selected source/channel/head CID, and preserved identity and data-marker hashes.
    Both installed Runtime binaries match built SHA-256 2041b4b021ed473330bc7cdbe8007a8bba9ee00e2ecb0f3730e784dd5a9ddace; both installed manifests match verified SHA-256 c9ee834e6934d5cfbe6b25f60fcc891eb341c9289512c7fb2dfa00ad8b7fc38e, including after changed-asset refresh.
    Run receipt SHA-256: 451979f97eae602639260eb3510c6580b754b7e50216ffe5cf267202d6f85aa7; recovery receipt: 838b6037f7e2b5fb572c68ac5eacf2a018c6311e8b0255517b737a910d8f2e0c. Private receipts bind exact source/tree, paths, artifacts and process evidence.
    All owned Runtime/provider/Kubo processes stopped; locks released and all three task ports are free. The checkout is clean and even with its remote.
    This proves explicit CLI recovery and F3 byte preservation. Operator Apply still exits during self-replacement, and automatic restart remains open. #107 stays open for evidence review, required human review and merge; the complete staged-update journey remains with the update lane.

  16. andersalm commented on Sep 30, 2026

    @andersalm
    ContributorAuthor

    UP-01 PR #132 is ready for human review at 47658723, tree 393b549aa8b3a25f23c9d7257b37e23d2b75cebc; irzhywau is requested.
    Reran the cancelled jobs in CI run 36735599578. Results are pending while work continues on #97 and #98.
    Accepted source tests, independent review, installed refusal/CLI Apply proof and explicit recovery receipts are reused. The candidate is clean and even with its fetched task remote; git merge-tree --write-tree confirms compatibility with models ea670e27.
    Operator Apply's exit 75 remains in the PR description. Source confirms binary replacement precedes the manifest write; complete-set staging and interrupted installation belong to #108, while automatic restart belongs to #109. Both issues now carry that exact failed result.
    #107 remains open for final evidence acceptance, green required checks, Irzhy's review and merge. Next: the renewed #97 visible Assistant test and #98 Linux x86-64 installed proof.

  17. andersalm commented on Sep 30, 2026

    @andersalm
    ContributorAuthor

    CI rerun 36735599578 attempt 2 passes all eight required jobs at 47658723; PR #132 is ready and awaits Irzhy's requested review.
    The branch is clean and matches origin/fix/0.7.1-update-validation (0 behind / 0 ahead); compatibility with current models base ea670e27 is clean.
    Accepted signed-validation and CLI-apply proofs remain unchanged. The operator-apply exit 75 stays visible, with complete staging in #108 and restart/recovery in #109.
    Next: resolve human review findings on #107; prepare #141 while the other task proof gates remain open.

  18. andersalm commented on Sep 30, 2026

    @andersalm
    ContributorAuthor

    Read-only follow-through confirms PR #132 remains at 476587230798e8418dfdc60730384ddacfbc5d5c, tree 393b549aa8b3a25f23c9d7257b37e23d2b75cebc; the task checkout is clean and remote divergence is 0/0.
    The eight required checks pass. irzhywau remains requested; review and inline-comment lists are empty. Accepted signed-refusal, CLI Apply and recovery receipts remain the proof for #107.
    For #108, the immediate change starts at update.rs:951: validate the staged executable before replacement and stage the full artifact set before the host-coordinated commit. Current version validation follows the rename at line 971, and support refresh follows the manifest replacement.
    Reuse test_staged_executable_refusal_preserves_installation_then_valid_retry_installs from the installer, the update wrong-content refusal, and exact manifest-byte refresh tests. Add interruption checks at the complete-set commit boundary using the accepted exit-75 receipt.
    #108 depends on #107 and a reviewed installation layout; #109 owns restart. Integration still requires Irzhy's candidate review. This check changed neither source nor artifacts.

  19. modified the milestones: 0.8.0, 0.7.2 on Sep 30, 2026
  20. andersalm commented on Sep 30, 2026

    @andersalm
    ContributorAuthor

    Published normal merge c87b0eb490c41905fe16452244d187a847b97e9f, tree 23a90ffd9ab8d20085e8fabb1dd0e658d34d6dd4, to origin/fix/0.7.1-update-validation for PR #132.
    The merge includes exact approved models commit 938a5926d920d5e3ef7a3260b1a375bf40be955c. Its incoming change is version/lock alignment, versioning documentation, changelog and the matching Carrier generation check; merge completed without conflicts or history rewrite.
    The current candidate passes git diff --check, Home entropy, workspace formatting, chain-provider formatting and node scripts/carrier-dependency-generation-check.mjs.
    Narrow checks pass: cargo test --locked -p elastos-server --lib update::tests (22), --lib refresh_installed_components_for_update (2), and --lib update_refresh_preserves_manifest_bytes_without_asset_changes (1). Tests ran from elastos/ using the existing task cache.
    All updater/support-refresh/operator/Carrier/release source remains byte-identical to 47658723. Its accepted installed refusals, CLI Apply and recovery receipts remain prior-candidate proof; this merge adds source compatibility evidence.
    The task branch is clean and remote divergence is 0/0. The existing private lifecycle ledger is updated; all owned build/test processes exited, and disk free space stays above 10%.
    GitHub changed the PR target to develop after the external branch rename. Approval of that target remains open; the approved issue target is unchanged. Irzhy's existing review request remains active, and PR readiness stays unchanged.
    Current-candidate CI and required human review remain open. #108 owns complete-set staging after #107 integration and installation-layout review; #109 owns restart. Installed Homes, keys and fixture data stayed unchanged.

  21. andersalm commented on Oct 1, 2026

    @andersalm
    ContributorAuthor

    PR #132 candidate ef24287c includes current develop and the F4 gateway-binding comment; all four basic gates pass, remote divergence 0/0.
    Irzhy's approve verdict and Anders's merge approval apply; accepted updater tests and installed proof remain valid for the comment-only task delta.
    F1/F3 continue in #156 (0.7.3); F2 freshness design continues in #157 (0.8.0). #108/#109 retain operator apply exit-75 staging and restart ownership.
    Prior CI 36785467102 passed eight required checks; the new candidate's CI is queued.
    Next: exact-candidate CI and compatible normal merge into develop; continue #137 while CI runs.

  22. andersalm commented on Oct 1, 2026

    @andersalm
    ContributorAuthor

    PR #132 candidate ef24287c is in QA / Review with all four basic gates passed and remote divergence 0/0.
    Exact-candidate CI 36855944616 is in progress in the single result snapshot; its completion is the remaining merge gate.
    Irzhy's approve verdict, Anders's authorization and accepted installed proof remain qualified. #156/#157 own follow-ups; #108/#109 own exit-75 staging/restart.
    Next: read the completed result, then verify current-base compatibility and merge with exact-head protection.

  23. andersalm commented on Oct 1, 2026

    @andersalm
    ContributorAuthor

    PR #132 candidate ef24287c: the single CI result read for run 36855944616 shows source-gate, lint, test-elastos and test-capsules passed; custody and the three source-home jobs remain in progress.
    The task branch is clean, matches its remote at 0/0, and contains current develop (de1db928).
    Irzhy's approve verdict and Anders's exact-candidate merge authorization remain valid; all required checks must finish green before merge.
    Next: read the completed result once and verify the current base before a normal merge. The branch and worktree remain retained.

  24. andersalm commented on Oct 1, 2026

    @andersalm
    ContributorAuthor

    PR #132 merged normally into develop: source ef24287c, merge 3cb27650; CI 36855944616 passed all eight required jobs.
    Irzhy's approve verdict and Anders's explicit authorization cover the F4 comment and compatible base merge; accepted independent review and installed validation/CLI recovery proof remain valid.
    All #107 Done means are proved. #156 owns F1/F3 hardening; #157 owns freshness design; #108/#109 retain the operator exit-75 staging/restart gap.
    Task source is clean and remote divergence is 0/0. Branch/worktree retirement remains an owner decision; next: merge #138, then start #156.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions