Found by the breaker while landing #43 (ByteBuddy checksum verification in agent/build.sh).
Where
install.sh:297 invokes bash "$HERE/agent/build.sh" >/dev/null (build.sh's stdout is discarded; only stderr surfaces). sha256sum -c writes its <path>: FAILED line — the one that names the rejected file — to stdout, and only the generic sha256sum: WARNING: 1 computed checksum did NOT match to stderr.
Why it matters
When the ByteBuddy checksum check added in #43 actually fires (a poisoned cache, a compromised mirror, or an operator error re-pinning the hash), an installer running install.sh sees only:
sha256sum: WARNING: 1 computed checksum did NOT match
with no filename, no path, and no indication it was ByteBuddy specifically. Anyone debugging a failed install has to go read agent/build.sh to work out what actually failed.
Why not fixed alongside #43
This is a different file (install.sh, not agent/build.sh) and fixing it well needs a design decision — e.g. whether install.sh should show build.sh's full stdout on failure only (tee to a log + show on non-zero exit), always stream it, or something else — rather than a one-line mechanical change.
Suggested fix
Have install.sh capture agent/build.sh's combined output and print it (or at least the tail) when the build step exits non-zero, instead of unconditionally discarding stdout.
Confidence: Confirmed. Severity: Low (build-time diagnostics only, no security impact) but directly affects how debuggable a real checksum failure is for whoever hits it.
Found by the breaker while landing #43 (ByteBuddy checksum verification in
agent/build.sh).Where
install.sh:297invokesbash "$HERE/agent/build.sh" >/dev/null(build.sh's stdout is discarded; only stderr surfaces).sha256sum -cwrites its<path>: FAILEDline — the one that names the rejected file — to stdout, and only the genericsha256sum: WARNING: 1 computed checksum did NOT matchto stderr.Why it matters
When the ByteBuddy checksum check added in #43 actually fires (a poisoned cache, a compromised mirror, or an operator error re-pinning the hash), an installer running
install.shsees only:with no filename, no path, and no indication it was ByteBuddy specifically. Anyone debugging a failed install has to go read
agent/build.shto work out what actually failed.Why not fixed alongside #43
This is a different file (
install.sh, notagent/build.sh) and fixing it well needs a design decision — e.g. whether install.sh should show build.sh's full stdout on failure only (tee to a log + show on non-zero exit), always stream it, or something else — rather than a one-line mechanical change.Suggested fix
Have
install.shcaptureagent/build.sh's combined output and print it (or at least the tail) when the build step exits non-zero, instead of unconditionally discarding stdout.Confidence: Confirmed. Severity: Low (build-time diagnostics only, no security impact) but directly affects how debuggable a real checksum failure is for whoever hits it.