Skip to content

fix(updater): refuse update under a package-manager receipt - #29

Merged
AlexMikhalev merged 1 commit into
mainfrom
fix/v1.21.16-update-refusal
Sep 25, 2026
Merged

AlexMikhalev merged 1 commit into
mainfrom
fix/v1.21.16-update-refusal

Conversation

@AlexMikhalev

Copy link
Copy Markdown
Contributor

Summary

Seal run 36178214528 proved the previous fixes work (the managed DEB/RPM build
step passed on both musl lanes for the first time) and surfaced the next
first-time runner: the actual-package native lifecycle gate. Both lanes failed
identically:

+ /usr/bin/terraphim-agent update
[OK] Managed by dpkg; run `sudo apt update && sudo apt upgrade` to update
+ echo update must refuse under a dpkg receipt
+ exit 1

terraphim-agent update under a package-manager receipt printed the
managed-by message but exited 0. The lifecycle gates require an explicit
update under a receipt to refuse. terraphim-cli already implements this
contract (Gitea #247: Err(anyhow!("{bin} update was refused: {other}"))), and
the C fixture in test_client_nfpm_native.sh replicates it — the agent and
grep binaries were the gap.

Changes

  • crates/terraphim_agent/src/main.rs: PackageManaged arm in the
    Command::Update handler — eprintln terraphim-agent update was refused: <status> and exit 1; all other statuses keep the current stdout/exit-0 path.
  • crates/terraphim_grep/src/main.rs: same arm in handle_update_command.
  • update_refusal_tests.rs in both crates: stage the real compiled binary
    into a temp prefix with a real dpkg/rpm receipt at
    <prefix>/share/terraphim/package-manager.d/<bin> (the updater's own
    path-derived detection — no mocks, no network, no system paths) and assert:
    • update exits non-zero under dpkg and under rpm
    • stderr contains the exact gate line
      terraphim-agent update was refused: [OK] Managed by dpkg; run \sudo apt update && sudo apt upgrade` to update`
    • the executable is byte-identical afterwards
    • check-update still prints the managed line on stdout and exits 0

Verification

  • cargo test -p terraphim_agent -p terraphim_grep --test update_refusal_tests:
    6/6 pass (3 per crate).
  • cargo test -p terraphim_agent --test learn_no_service_tests (4/4) and
    cargo test -p terraphim_grep --test no_thesaurus_cli (1/1) still pass.
  • cargo fmt --check clean.
  • The refusal string and message formats are byte-identical to the gate's
    grep -Fxq patterns (dpkg and rpm variants, host and docker paths).

Refs #337

Seal run 36178214528 moved past the relative-path fix (the managed DEB/RPM
build step passed on both musl lanes for the first time) and hit the next
first-time runner, the actual-package native lifecycle gate: `terraphim-agent
update` under a dpkg receipt printed the managed-by message but exited 0.

The Gitea #247 contract -- already implemented by terraphim-cli and by the C
fixture in test_client_nfpm_native.sh -- requires an explicit `update` under
a receipt to exit non-zero, print "<bin> update was refused: <status>" to
stderr, and leave the installed binary byte-identical, while `check-update`
keeps reporting the managed status on stdout with a zero exit.

- terraphim_agent: PackageManaged arm in the Command::Update handler
  (eprintln the refusal line, exit 1)
- terraphim_grep: same arm in handle_update_command
- update_refusal_tests.rs in both crates: stage the real compiled binary into
  a temp prefix with a real dpkg/rpm receipt (the updater's own path-derived
  detection) and assert exit code, exact stderr line, and unchanged bytes;
  check-update asserts the stdout line and zero exit. No network, no mocks.

All six refusal tests pass against the real binaries; learn_no_service_tests
and no_thesaurus_cli still pass; rustfmt clean.

Refs #337
@AlexMikhalev
AlexMikhalev merged commit cf23b9b into main Sep 25, 2026
2 checks passed
@AlexMikhalev
AlexMikhalev deleted the fix/v1.21.16-update-refusal branch September 25, 2026 19:43
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