lua/samples/github_download.lua: script keeps running (and logs a false "hashes are matches") after a checksum mismatch #186

New issue

Closed

opened 2026-09-17 22:11:38 +00:00 by advisor-bot · 0 comments

advisor-bot commented

2026-09-17 22:11:38 +00:00

Owner

Description

The entire purpose of this script is to download a release artifact and its checksum file, then verify the artifact's integrity before using it. On mismatch it logs an error and deletes the downloaded (untrusted/corrupt) file — but never stops the script:

if actual_hash ~= required_hash then
    atis.log.error("hashes are different", {
        required_hash = required_hash,
        actual_hash = actual_hash,
    })
    err = atis.file.delete("/tmp/" .. tar_name)
    atis.misc.unwrap(err)
end

atis.log.info("hashes are matches", {
    required_hash = required_hash,
    actual_hash = actual_hash,
})

There is no os.exit(1)/return inside the if block, so execution falls straight through to the unconditional atis.log.info("hashes are matches", ...) line — which is logged even though the hashes were just reported as different, a directly self-contradicting pair of log lines. Execution then continues to atis.misc.unzip_targz("/tmp/" .. tar_name, uncomp_dest) against a file that line 52 just deleted, so in the current version of the script it happens to fail a few statements later via unwrap on a "file not found"-style error — but only incidentally, and with a confusing failure message that has nothing to do with the real problem (a failed checksum verification). If the cleanup-on-mismatch step were ever changed or removed, this would go on to unpack a corrupted/tampered artifact despite having already detected the checksum mismatch.

Location

lua/samples/github_download.lua:47-59

Risk

Medium-high. This script exists specifically to defend against a corrupted or tampered download (a supply-chain integrity check), and the one case it's supposed to react to — a verification failure — does not stop execution as intended. Since this is a sample meant to demonstrate the "correct" checksum-verification pattern in Atis for others to copy, the flaw undermines the exact security property the pattern is supposed to provide.

Suggested fix

Call os.exit(1) (or return) immediately inside the if actual_hash ~= required_hash then block, right after logging/cleanup, so a verification failure halts the script instead of falling through to the "hashes are matches" log line and the subsequent unpack step.

## Description The entire purpose of this script is to download a release artifact and its checksum file, then verify the artifact's integrity before using it. On mismatch it logs an error and deletes the downloaded (untrusted/corrupt) file — but never stops the script: ```lua if actual_hash ~= required_hash then atis.log.error("hashes are different", { required_hash = required_hash, actual_hash = actual_hash, }) err = atis.file.delete("/tmp/" .. tar_name) atis.misc.unwrap(err) end atis.log.info("hashes are matches", { required_hash = required_hash, actual_hash = actual_hash, }) ``` There is no `os.exit(1)`/`return` inside the `if` block, so execution falls straight through to the unconditional `atis.log.info("hashes are matches", ...)` line — which is logged even though the hashes were just reported as different, a directly self-contradicting pair of log lines. Execution then continues to `atis.misc.unzip_targz("/tmp/" .. tar_name, uncomp_dest)` against a file that line 52 just deleted, so in the current version of the script it happens to fail a few statements later via `unwrap` on a "file not found"-style error — but only incidentally, and with a confusing failure message that has nothing to do with the real problem (a failed checksum verification). If the cleanup-on-mismatch step were ever changed or removed, this would go on to unpack a corrupted/tampered artifact despite having already detected the checksum mismatch. ## Location `lua/samples/github_download.lua:47-59` ## Risk Medium-high. This script exists specifically to defend against a corrupted or tampered download (a supply-chain integrity check), and the one case it's supposed to react to — a verification failure — does not stop execution as intended. Since this is a sample meant to demonstrate the "correct" checksum-verification pattern in Atis for others to copy, the flaw undermines the exact security property the pattern is supposed to provide. ## Suggested fix Call `os.exit(1)` (or `return`) immediately inside the `if actual_hash ~= required_hash then` block, right after logging/cleanup, so a verification failure halts the script instead of falling through to the "hashes are matches" log line and the subsequent unpack step.