Five host-setup/ sites swallow a precondition-check failure with || true or
2>/dev/null before a mutation runs, recurring finding from CodeRabbit across
PR #951 and PR #952.
The pattern
Each site converts a command failure into an empty or apparently-safe result,
then proceeds into a download, package install, sudoers-file write, or release
upgrade as if the check had passed:
host-setup/bootstrap.sh:86: resolve_ref() falls back to the moving $REF
when commit resolution fails, instead of aborting.host-setup/linux/install-tools.sh:245: apt_install_displacing() treats a
failed apt-get -s install simulation as "no removals" instead of stopping
before the real install.host-setup/linux/install-tools.sh:1415-1417: the sudoers scan does not
distinguish grep exit status 1 (no matches, expected) from a real scan
error, before writing or deleting sudoers files.host-setup/linux/upgrade-host.sh:245: proceeds into source rewriting and
the release upgrade even if dpkg --audit itself failed to run, rather than
only checking for packages the audit found.host-setup/linux/upgrade-host.sh:177: upgradable_count()'s
apt list --upgradable 2>/dev/null | grep -c '/' || true reports 0
upgradable packages both when there genuinely are none and when
apt list itself failed.
Where this was raised
Per pr-review-conduct's outcome 5 ("keeps recurring, so fix the class, not
the instance"), a finding shape raised twice against the same repo is the
signal to resolve the class here rather than keep re-declining each instance
piecemeal.
Ask
Review each site and decide, per site, whether the lenient fallback is
deliberate (and if so, say why inline so this stops resurfacing) or should
fail closed before the mutation it currently guards.
Five
host-setup/sites swallow a precondition-check failure with|| trueor2>/dev/nullbefore a mutation runs, recurring finding from CodeRabbit acrossPR #951 and PR #952.
The pattern
Each site converts a command failure into an empty or apparently-safe result,
then proceeds into a download, package install, sudoers-file write, or release
upgrade as if the check had passed:
host-setup/bootstrap.sh:86:resolve_ref()falls back to the moving$REFwhen commit resolution fails, instead of aborting.
host-setup/linux/install-tools.sh:245:apt_install_displacing()treats afailed
apt-get -s installsimulation as "no removals" instead of stoppingbefore the real install.
host-setup/linux/install-tools.sh:1415-1417: the sudoers scan does notdistinguish
grepexit status 1 (no matches, expected) from a real scanerror, before writing or deleting sudoers files.
host-setup/linux/upgrade-host.sh:245: proceeds into source rewriting andthe release upgrade even if
dpkg --audititself failed to run, rather thanonly checking for packages the audit found.
host-setup/linux/upgrade-host.sh:177:upgradable_count()'sapt list --upgradable 2>/dev/null | grep -c '/' || truereports 0upgradable packages both when there genuinely are none and when
apt listitself failed.Where this was raised
flagged
bootstrap.sh:86plus the other 4 sites in one consolidated finding.Declined there as pre-existing code unrelated to that PR (confirmed
byte-identical against the base commit).
recurred against
install-tools.sh:245,install-tools.sh:1415-1417,upgrade-host.sh:245, and a new site,upgrade-host.sh:177. Declined againon the same evidence.
Per
pr-review-conduct's outcome 5 ("keeps recurring, so fix the class, notthe instance"), a finding shape raised twice against the same repo is the
signal to resolve the class here rather than keep re-declining each instance
piecemeal.
Ask
Review each site and decide, per site, whether the lenient fallback is
deliberate (and if so, say why inline so this stops resurfacing) or should
fail closed before the mutation it currently guards.