Buildroot Git Downloads: Explain a Cached Archive After a Missing-Hash Failure

A Git-derived source archive can exist in Buildroot's download directory even though the download stage returned failure. Before treating that file as approved input, distinguish a missing checksum entry from an actual checksum mismatch. The saved pathname and the final command result answer different questions.

This article examines Buildroot 2026.08 with ordinary hash checking and no explicit hash exemption for the file. It follows a specific missing-entry path, not every downloader error. No download, build or integrity attack was executed. The example is a proposed diagnostic fixture, and no existing package is alleged to have incorrect integrity metadata.

Start with the exact basename

A recipe change can alter the expected generated archive name while a maintained hash file still lists another name. Record the archive basename passed to the checker and compare it with the filename column of the actual hash files selected for this build. Similar-looking version strings do not make two names interchangeable.

The tagged hash checker compares entries against that final basename. Its outcomes distinguish an existing hash file with no matching entry from a matching entry whose digest fails. It also treats the absence of all hash files differently. Keep these categories separate in the diagnostic record rather than calling every failure “a bad download.”

For a hypothetical Git package update, the new archive has a changed revision component in its filename. A hash file exists but only names the old archive. Successful retrieval of the new bytes cannot satisfy an entry that does not identify them.

Follow the newly downloaded file path

The 2026.08 download wrapper handles the missing-entry result specially after downloading into temporary storage. That path retains a failure result but proceeds to place the file at its final download location. Consequently, finding the file afterward does not contradict the failed command.

This is a useful distinction for build automation. A script that checks only whether the archive exists can accidentally promote an unresolved source to an accepted input. Preserve the stage exit status and the checker's diagnostic alongside the path. Do not rewrite a failed preparation result as success because a later directory listing looks complete.

The wrapper's atomic placement concerns visibility of the saved file. It does not turn a missing integrity decision into a successful one. File installation and acceptance remain separate observations in this branch.

Understand why an immediate retry may not download again

When that file already exists, the wrapper checks it before attempting another source location. A missing matching hash entry is a hard failure on this existing-file path; it does not take the mismatch path that removes the cached file and attempts retrieval again.

Therefore repeated attempts against the same metadata can reproduce the error without new network traffic. Changing mirror priority is unlikely to address a basename absent from the selected hash records. Inspect the metadata first instead of interpreting a quiet network trace as proof that the downloader is stuck.

Do not delete the only copy of the failed artifact during diagnosis. Preserve a separate permitted evidence copy, its observed digest and the log. A disposable download directory is a better place to reproduce behavior than a shared release cache.

Repair the evidence relationship deliberately

A newly calculated digest tells you the identity of the bytes you have. It does not, by itself, establish that those are the intended sources. Check repository revision, source preparation options and the reviewed artifact provenance before changing an expected hash entry.

If the recipe name is wrong, correct the recipe under normal review. If the integrity metadata is incomplete, add the justified entry for the intended artifact. Do not erase the hash file or create an exemption simply to make the stage pass. Keep the prior accepted release inputs available according to the project's retention policy.

Exercise three independent fixture cases

In an isolated test, compare a valid matching entry, a deliberately mismatching digest and an existing hash file without this basename. For each case record the checker category, wrapper result, whether a file remains and whether another download was attempted. Also identify any explicit exemption, since it changes the missing-entry premise.

These are proposed observations, not measured outcomes. The acceptance criterion is that automation preserves the real preparation result. A cached file can be valuable investigation evidence while still being unsuitable for an approved build.