bug(arcup): read rejects valid .sha256 files that have no trailing newline

[osr21]

Problem

verify_checksum_file() in arcup/arcup decides whether a checksum file is empty from the exit status of read:

if ! read -r expected_checksum expected_name < "$checksum_path"; then
    error "Checksum file is empty: $checksum_path"
fi

read returns a non-zero exit status when it reaches EOF before encountering a newline — even when it has already successfully assigned the variables. Under set -euo pipefail a valid .sha256 file whose single line has no trailing newline is therefore rejected with Checksum file is empty, aborting an otherwise-correct install.

Several common tools produce .sha256 files without a trailing newline (e.g. printf '%s %s' "$hash" "$file" rather than echo), so this is a real-world failure path.

Repro

# Create a valid checksum file without a trailing newline
printf '%s  arc.tar.gz' "$(sha256sum arc.tar.gz | cut -d' ' -f1)" > arc.tar.gz.sha256
# arcup aborts with: "Checksum file is empty: arc.tar.gz.sha256"
# The hash is never read or compared.

A file produced by echo (trailing newline) is accepted. A file produced by printf (no trailing newline) is rejected, even though both contain identical data.

Proposed fix

Decide emptiness from the parsed hash rather than from read's exit status:

read -r expected_checksum expected_name < "$checksum_path" || true
if [[ -z "$expected_checksum" ]]; then
    error "Checksum file is empty: $checksum_path"
fi

The || true suppresses the non-zero exit on EOF-before-newline; the subsequent [[ -z ... ]] guard still rejects a genuinely empty file. All four combinations in the newline × validity matrix should be pinned by tests:

newline	hash valid	expected result
yes	yes	pass
no	yes	pass (currently fails)
yes	no	fail (mismatch)
no	no	fail (mismatch)

[osr21]

I would like to work on this. Could a maintainer please assign me?

I have a fix ready (the read || true + [[ -z ]] guard described above) along with a test suite that covers all four combinations in the newline × validity matrix (28 assertions, all passing). I will open a PR with Closes: #448 in the description once assigned.

[UzairRehman4]

Hi maintainers, this looks like the same root cause as #420 (read's exit status in verify_checksum_file misinterpreted as an empty checksum file when there's no trailing newline). I have a fix ready covering both. Could I be assigned to this issue so I can open a PR per the contributing guidelines? Thanks!