fix: ensure Helm prerequisites on Tier 0 install path (Bugbot #383)

[shujaatTracebloc]

Resolves a High-severity Cursor Bugbot finding on the client promotion PR (#383, develop → main).

Bug: The Tier 0 fast path (install_linux, scripts/lib/setup-linux.sh) returns after _install_userspace_tools and never runs install_system_deps — but _install_userspace_tools → install_helm still shells out to get-helm-3, which needs openssl (checksum verification) and tar (unpack). Those packages are installed only in install_system_deps, and the file itself notes minimal cloud images (Amazon Linux 2023, minimal RHEL) ship neither. So on a docker-group host without them, the "zero-privilege" install promised no admin and then failed mid-Helm-install.

Fix: New _ensure_helm_prereqs helper, called on the Tier 0 path before _install_userspace_tools. It verifies openssl+tar are present. We deliberately do not install them there: on Tier 0 every package install requires sudo ($PM_INSTALL is sudo-prefixed and setup_pm isn't even run on this path), which would break the "no administrator rights needed" promise. So when they're genuinely missing it fails fast with an actionable message (install them once / ask an admin, then re-run) instead of silently sudo-ing or dying cryptically. Hosts with a usable Docker almost always have both, so the common case is a silent no-op. The full flow is unchanged — install_system_deps still installs them.

Coverage: added _ensure_helm_prereqs unit tests (present → no-op; missing → fatal naming the packages + the zero-privilege constraint) and assert it runs on the Tier 0 branch in install_linux.

#383 (comment)

Lands on develop; the promotion PR head picks it up on the next develop sync and Bugbot re-reviews.

🤖 Generated with Claude Code

---

Note

Low Risk
Narrow change to the Tier 0 branch only; no sudo or package installs added, with bats and manifest checksum updated.

Overview
Fixes Bugbot #383: the Tier 0 Linux installer skips install_system_deps but still runs install_helm via get-helm-3, which needs openssl and tar—so minimal images could fail mid-Helm after advertising a zero-privilege install.

Adds _ensure_helm_prereqs, invoked on the Tier 0 path before _install_userspace_tools. It only checks that those tools exist; it does not install packages (that would require sudo and break the Tier 0 promise). When they’re missing, the installer exits early with a message to install them or ask an admin. Tier 1/2 behavior is unchanged (install_system_deps still provides them).

Bats cover the helper (no-op vs fatal) and assert Tier 0 install_linux calls it; scripts/manifest.sha256 is updated for setup-linux.sh.

^{Reviewed by Cursor Bugbot for commit 50bc8d8. Bugbot is set up for automated code reviews on this repo. Configure here.}

[LukasWodka]

Thanks for this — the finding is fully real (Tier 0 skips install_system_deps, and get-helm-3 dies without openssl/tar on AL2023/minimal RHEL).

Product direction from Lukas on the remedy though: the installer should take care of its own requirements, not error out and tell the user to install tools. #396 implements that direction and supersedes the fail-fast approach here:

• openssl is no longer needed at all — Helm is now downloaded directly from get.helm.sh (pinned HELM_VERSION, verified against the published .sha256sum with coreutils sha256sum, fail-closed), mirroring the k3d direct download from fix(installer): pin the k3d release (K3D_VERSION) — deterministic, rate-limit-proof installs #382. This also stops us executing get-helm-3 off the mutable helm/helm@main.
• tar/gzip, when genuinely missing on Tier 0, get installed via the package manager (quietly with root/passwordless sudo; honest one-line password ask otherwise) instead of aborting.

Leaving this PR open for you/Lukas to close once #396 lands.

[LukasWodka]

bugbot run

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 50bc8d8. Configure here.}