Stale checksum pins for rust and atuin — identical on the release commit and main, so --checksums-ref main cannot help (recurrence of #398; monitor flapping per #457)

Summary

Two checksums.yaml pins are stale against live upstream, so ACFS refuses to install lang.rust and tools.atuin with Security Error: Checksum mismatch. Contrary to the error text, main does not carry refreshed values — the entries are byte-identical on the release commit and on main, so neither --checksums-ref main nor waiting helps.

This is a recurrence of #398, which reported tools.atuin stale on v0.9.0 with different hashes. So the pin was refreshed after #398 and has gone stale again — the underlying cause is that these URLs are moving targets, not a one-off missed refresh.

Environment

ACFS version: 0.10.0
Release commit: ba924f17f4b00a6c4b57966570633e27c9422c69
main at test time: 405de32b3e8c22aadc90c8783d1694fdf48ddf92
OS: Omarchy 4.0.6 (ID=omarchy, ID_LIKE=arch)
Date observed: 2026-10-21

Observed mismatches

ERROR: Security Error: Checksum mismatch for rust
  Expected: 7d0ea0f8eba7fa1ebfe998091cd7ec4501e33ec5ca6b884eb4d894d7da5170af
  Actual:   9502b514362a21096210d498f143b8cdacda365d3dfcf45e8f5541e089ccafc0
  URL: https://sh.rustup.rs

ERROR: Security Error: Checksum mismatch for atuin
  Expected: e632c6d1dc71e75c9710caf5f645c11131f0d94c859ed6b4266444e11240abdb
  Actual:   69c7c0e057084ede4536de25f856c037f4649dcf8f29cc98a64ac52340320a99
  URL: https://github.com/atuinsh/atuin/releases/latest/download/atuin-installer.sh

main has the same stale values

Fetched checksums.yaml from both refs and compared — identical entries:

# identical at ba924f17… and at main (405de32b…)
atuin:
  url: "https://github.com/atuinsh/atuin/releases/latest/download/atuin-installer.sh"
  sha256: "e632c6d1dc71e75c9710caf5f645c11131f0d94c859ed6b4266444e11240abdb"
rust:
  url: "https://sh.rustup.rs"
  sha256: "7d0ea0f8eba7fa1ebfe998091cd7ec4501e33ec5ca6b884eb4d894d7da5170af"

The error text states:

End users: checksums.yaml is refreshed from upstream automatically, so a mismatch on a current ACFS means the PUBLISHED pin is stale

For these two entries that automatic refresh has not happened on main, so the only recourse the message offers (acfs hold) leaves the tools permanently uninstalled.

Likely reason the drift went unnoticed: #457

The checksum monitor has been flapping for the past week — all comments on #457 are automated alerts:

Drift monitoring was therefore intermittently down across the window in which these two pins went stale, and the last recorded state is fail-closed. Fixing #457 is probably a prerequisite for these pins staying fresh.

Cascade

tools.ast_grep installs via ~/.cargo/bin/cargo install ast-grep --locked, so the lang.rust failure cascades into it:

ERROR: tools.ast_grep: install command failed: ~/.cargo/bin/cargo install ast-grep --locked

Root cause: unpinnable URLs

Both entries point at moving targets:

• https://sh.rustup.rs — a live script that changes whenever rustup ships.
• …/releases/latest/download/atuin-installer.sh — latest by definition.

Neither can be pinned durably, so both will drift again immediately after any refresh. #435 reports the same class of problem for AADC ("still builds unpinned main despite published installer and binaries").

Suggested fix

1. Re-pin rust and atuin via ./scripts/lib/security.sh --update-checksums.
2. Prefer immutable, versioned URLs over latest/download/ and sh.rustup.rs — e.g. pin a specific atuin release tag, and for rustup pin a versioned rustup-init artifact rather than the live bootstrap script. Where a distro package is a viable source (Arch ships atuin and rustup in extra), consider allowing that path to satisfy the module instead.
3. Soften the end-user text: it currently promises an automatic refresh that did not occur here, and offers acfs hold as the only recourse. When main and the release commit carry the same stale hash, saying so explicitly would save users from trying --checksums-ref main.
4. Surface stale pins in acfs doctor as a distinct state from "install failed", so users can tell an upstream pin problem from a local one.

Workaround used

Skipped the module and installed from Arch extra instead:

sudo pacman -S --needed atuin rustup
rustup default stable     # rust 1.99.1

Note this does not satisfy either module's installed_check — lang.rust tests test -x ~/.cargo/bin/cargo while Arch's rustup places proxies in /usr/bin, and tools.atuin requires ~/.atuin/bin/atuin plus an ACFS-generated wrapper marker. Reported separately in the Arch/Omarchy generated-modules issue.

Related

#398 (same class, v0.9.0, closed), #457 (monitor failing closed — likely why this drifted), #435 (unpinned main builds), #468 (checksums.yaml re-pin breaking bootstrap integrity).