Hmbown/CodeWhale · error · anyhow::Error

{} from {} does not list {}; refusing to download an unverif

Error message

{} from {} does not list {}; refusing to download an unverified update

What it means

While building the download plan, the release's checksum manifest asset (e.g. SHA256SUMS) downloaded and parsed correctly, but contains no entry keyed by this platform's binary asset name. Because the updater refuses to download any update it cannot checksum-verify, it aborts here.

Source

Thrown at crates/cli/src/update.rs:855

        download_url(&checksum_asset.browser_download_url, proxy).with_context(|| {
            format!(
                "failed to download {} from {}\n{}",
                checksum_asset.name,
                fetched.source.describe(),
                update_network_fallback_hint()
            )
        })?;
    let checksum_text = std::str::from_utf8(&checksum_bytes)
        .with_context(|| format!("{} is not valid UTF-8", checksum_asset.name))?;
    let checksums = parse_checksum_manifest(checksum_text).with_context(|| {
        format!(
            "failed to parse {} from {}",
            checksum_asset.name,
            fetched.source.describe()
        )
    })?;
    if !checksums.contains_key(&asset.name) {
        bail!(
            "{} from {} does not list {}; refusing to download an unverified update",
            checksum_asset.name,
            fetched.source.describe(),
            asset.name
        );
    }

    Ok(DownloadPlan {
        source: fetched.source.clone(),
        binary_name: asset.name.clone(),
        binary_url: asset.browser_download_url.clone(),
        checksums,
    })
}

fn manifest_probe_fetcher(proxy: Option<&Proxy>) -> Arc<ManifestFetcher> {
    let proxy = proxy.cloned();
    Arc::new(move |candidate: &ReleaseSourceCandidate| {

View on GitHub (pinned to 0c42157ee5)

Solutions

1. Report the affected release tag to the maintainers so the checksum manifest is republished
2. Update to a different version whose manifest lists the asset correctly
3. If you publish these releases yourself, regenerate the manifest from the exact shipped asset names (sha256sum over the final filenames) and re-upload
4. Verify the asset name in the message against the release's file list to spot naming mismatches

Example fix

# before: SHA256SUMS lists a differently named asset
9f2c...01  codewhale-linux-arm64.gz

# after: name matches the release asset exactly
9f2c...01  codewhale-linux-arm64.tar.gz

// Before relying on self-update for a release, verify its manifest covers your asset:
fn manifest_covers_asset(manifest_text: &str, asset_name: &str) -> bool {
    manifest_text
        .lines()
        .any(|l| l.trim().split_whitespace().nth(1)
            .map(|n| n.trim_start_matches('*')) == Some(asset_name))
}

// e.g. fetch SHA256SUMS for the tag, then:
assert!(manifest_covers_asset(&text, "codewhale-linux-arm64.tar.gz"));

Catch the refusal, surface the asset name and source from the message, and direct users to pin a known-good version or wait for a republished manifest; do not offer to skip checksum verification.

When it happens

Trigger: Self-update (or a programmatic call into the update-planning path) for a release whose checksum manifest is missing the asset line, or where the asset name in the manifest does not exactly match the release asset name (suffix, casing, .tar.gz vs raw).

Common situations: A release published with regenerated/renamed assets but a stale checksum manifest, hand-edited manifests with typos, or a partially published release.

Related errors

• no release source published a usable {CHECKSUM_MANIFEST_ASSE
• {} does not list {}
• no release source publishes an asset for this platform
• invalid SHA256 manifest line {}: {trimmed}
• SHA256 mismatch for {} from {}! expected: {expected} act

AI-assisted analysis of Hmbown/CodeWhale@0c42157ee5 (2026-08-20). Data as JSON: /api/errors/6d5540ffea0fb1ab. Report an issue: GitHub.