tonhowtf/omniget · critical

yt-dlp: verificacao de integridade impossivel

Error message

yt-dlp: verificacao de integridade impossivel — {}

What it means

Before installing the downloaded yt-dlp, the code fetches the release's `SHA2-256SUMS` file and derives the expected hash. If that sums file cannot be retrieved, the code fails closed: it cannot distinguish a transient GitHub hiccup from an attacker suppressing the checksum, so the binary is discarded and this error is raised. The message embeds the underlying cause.

Solutions

  1. Retry — a transient GitHub failure is the most common cause; ensure the whole release (asset + sums) is fetchable.
  2. Check proxy/firewall allows reaching the sums URL on the same host as the asset.
  3. Verify the target release actually publishes SHA2-256SUMS; pin to a release that does.
  4. If it persists, compare the asset hash manually against the published sums to rule out tampering, then investigate network paths.
Defensive patterns

Strategy: retry

Validate before calling

// preflight: confirm the sums file is reachable before starting the download
let sums_ok = client.head(&sums_url).send().await
    .map(|r| r.status().is_success()).unwrap_or(false);
if !sums_ok { eprintln!("SHA2-256SUMS unreachable; install will fail closed"); }

Try / catch

match download_ytdlp_binary().await {
    Err(e) if e.to_string().contains("verificacao de integridade impossivel") => {
        // transient? retry after backoff; if persistent, verify hashes manually
    }
    other => other?,
}

Prevention

When it happens

Trigger: `integrity::expected_from_sums_url` fails — sums URL unreachable, HTTP error, asset absent from SHA2-256SUMS, or network/timeout problems while fetching the checksum file.

Common situations: GitHub outage or rate limiting while fetching SHA2-256SUMS; corporate proxy stripping the request; a release published without the checksum file; tampering/MitM attempts (the fail-closed case this exists for).

Understand the failure class

Background: Checksum mismatch errors: "checksum verification failed", "digest mismatch", "expected vs actual checksum" — what they mean and how to fix them — this error's family across 41 libraries.

Related errors


AI-assisted analysis of tonhowtf/omniget@8600b91f42 (2026-09-12). Data as JSON: /api/errors/552ab3e4d4c0b31f. Report an issue: GitHub.

Appendix: source

Thrown at src-tauri/omniget-core/src/core/ytdlp.rs:1873

    if !response.status().is_success() {
        return Err(anyhow!(
            "Failed to download yt-dlp: HTTP {}",
            response.status()
        ));
    }

    let bytes = response.bytes().await?;

    // Verify against the release's published checksums. Fail closed on a
    // mismatch; fail open only when the sums file itself can't be fetched, so
    // a transient GitHub hiccup doesn't block downloads entirely.
    // Fail-closed. O yt-dlp publica `SHA2-256SUMS` em toda release; não
    // conseguir buscá-lo é indistinguível de alguém suprimindo a verificação,
    // então o binário é descartado em vez de instalado sem conferência.
    let expected = integrity::expected_from_sums_url(&client, &sums_url, asset)
        .await
        .map_err(|e| anyhow!("yt-dlp: verificacao de integridade impossivel — {}", e))?;
    integrity::verify_sha256(&bytes, &expected, &format!("yt-dlp ({:?})", channel))?;

    let temp = target.with_file_name(format!(
        "{}.new",
        target
            .file_name()
            .and_then(|n| n.to_str())
            .unwrap_or("yt-dlp")
    ));
    let temp_clone = temp.clone();
    tokio::task::spawn_blocking(move || std::fs::write(&temp_clone, &bytes))
        .await
        .map_err(|e| anyhow!("spawn_blocking failed: {}", e))??;

    crate::core::dependencies::replace_managed_binary(&temp, &target)?;

    #[cfg(unix)]
    {

View on GitHub (pinned to 8600b91f42)