The Download Page Is a Lie: What I Actually Check Before Installing

I've spent the better part of a decade maintaining internal tooling for Windows-based developer teams. And if there's one thing I've learned, it's that the download page—that polished grid of buttons, version numbers, and "Latest Release" badges—is the least trustworthy part of any open-source project. Not because maintainers are malicious, but because the page is optimized for the happy path. The real information lives in the release notes, the checksums, the issue tracker, and the raw file listing. This article is about how I actually read a download page, using a real example I pulled from GitVaults recently: the artempyanykh/marksman release from 2026-02-08.

The First Pass: What I Ignore on Purpose

When I land on a download page, I don't look at the big green button first. I look at the metadata around it. Specifically, I want to know three things before I click anything:

1. The exact commit or tag hash – not just the semantic version. A tag like v1.4.2 can be moved, deleted, or point to a different tree than what the page claims.
2. The build date and time – not the "published on" date, which is when someone pushed a button, but the actual compilation timestamp embedded in the binary.
3. The list of files – not the "Download for Windows" button, but the full asset manifest. If I see a .exe, a .msi, a .zip, and a .sha256, that tells me more about the release process than any changelog.

For the Marksman release I pulled, the page showed a standard layout: marksman-2026-02-08-win-x64.zip and marksman-2026-02-08-win-x64.exe. But the file listing also had a checksums.txt and a manifest.json. That's a good sign. It means the maintainer is thinking about reproducibility, not just convenience.

Here's the first command I run, right from the download page's asset URL. I don't use the browser's "Save As". I use curl with explicit flags so I can see the HTTP headers and the actual file size before committing to the download:

# PowerShell, but run from a clean temp directory
$url = "https://gitvaults.com/download/2026/02/08/artempyanykh-marksman-2026-02-08/en/marksman-2026-02-08-win-x64.zip"
$out = "marksman-2026-02-08-win-x64.zip"
curl.exe -L -A "Mozilla/5.0 (Windows NT 10.0; Win64; x64)" -o $out -w "HTTP %{http_code} | Size: %{size_download} bytes | Time: %{time_total}s`n" $url

If the HTTP code is 200 but the size is suspiciously small (like 3 KB), that's not the binary—that's an HTML error page or a redirect loop. I've seen that more times than I care to admit. The -A user agent matters because some CDNs serve different content to non-browser clients.

The Second Pass: Checksums and the Manifest Are the Real Download Page

The actual download page is just a pretty wrapper. The checksums.txt file is the contract. I always fetch it before I fetch the binaryasi. Here's my workflow, which I've refined after a few too many "works on my machine" incidents:

# Fetch the checksum file and the manifest first
$base = "https://gitvaults.com/download/2026/02/08/artempyanykh-marksman-2026-02-08/en"
curl.exe -L -o checksums.txt "$base/checksums.txt"
curl.exe -L -o manifest.json "$base/manifest.json"

# Show the expected SHA256 for the zip we want
Select-String -Path checksums.txt -Pattern "marksman-2026-02-08-win-x64.zip"

Now, here's the edge case that trips up most people: the checksums file might use a different algorithm than the one your tooling defaults to. I've seen projects switch from SHA256 to SHA512 mid-stream, or worse, use a custom "hash" that's actually a base64-encoded signature. So I don't just compare visually. I compute the hash of the downloaded file and compare it programmatically:

$downloadedHash = (Get-FileHash -Algorithm SHA256 -Path "marksman-2026-02-08-win-x64.zip").Hash
$expectedHash = (Select-String -Path checksums.txt -Pattern "marksman-2026-02-08-win-x64.zip").Line.Split(' ')[0]

if ($downloadedHash -eq $expectedHash) {
    Write-Host "HASH OK: $downloadedHash" -ForegroundColor Green
} else {
    Write-Host "HASH MISMATCH: expected $expectedHash got $downloadedHash" -ForegroundColor Red
}

This catches a real failure mode: some download pages serve a stale checksum file. The file listing on the page says "v1.4.2" but the checksums.txt was never updated when the maintainer rebuilt the binary after a last-minute fix. I've seen this happen with a project that had a flaky CI pipeline. The page showed the new date, but the checksums file still had the old hash. Without this check, I would have installed a binary that didn't match the documented release.

The Third Pass: Reading the Manifest for Dependency Clues

The manifest.json is where the download page's marketing ends and the engineering begins. I open it with jq if available, or just parse it in PowerShell. I'm looking for two specific fields: runtime and dependencies. The runtime tells me if this is a self-contained binary or if it needs .NET 8.0 Desktop Runtime installed. The dependencies list tells me if I need to install anything else, like a Visual C++ Redistributable.

Here's a concrete example from the Marksman manifest I pulled:

{
  "artifact": "marksman-2026-02-08-win-x64.zip",
  "runtime": "self-contained",
  "dependencies": [],
  "os": "windows",
  "arch": "x64",
  "build_id": "20260208.1142",
  "signature": "RSA-SHA256"
}

The build_id is gold. It tells me the exact build pipeline run, which I can cross-reference with the project's CI logs. If the download page says "stable" but the build_id is from a pull request that was never merged, that's a red flag. I've seen projects accidentally publish a feature branch as the "latest release" because someone fat-fingered a tag.

Another thing I check in the manifest: the signature field. If it says RSA-SHA256, I expect a .sig file next to the binary. If that file is missing from the asset list, I know the signing step was skipped, and I treat the binary as untrusted. This is a silent failure mode—the download page won't tell you the binary is unsigned. You have to check the file listing yourself.

The Fourth Pass: Actually Installing and Testing, Not Just Extracting

Most people stop after the hash matches. I don't. The download page says "portable", but portable can mean different things. I extract to a temp directory and run the binary with --version and --help before I ever put it in my PATH. Here's the exact sequence I use:

Expand-Archive -Path "marksman-2026-02-08-win-x64.zip" -DestinationPath ".\marksman-test"
cd .\marksman-test
.\marksman.exe --version
.\marksman.exe --help | Select-Object -First 20

The --version output should match the version on the download page. If it doesn't, that's a serious red flag. I've had a case where the download page said v1.4.2 but the binary printed v1.4.1 because the maintainer forgot to bump the version constant in the source code. The build was fine, the hash matched, but the binary was mislabeled. That's not a security issue, but it is a versioning issue that will bite you later when you're debugging a regression.

Another test: I check if the binary tries to phone home. I run it with --verbose and watch for network calls. On Windows, I use netstat after running the binary for a few seconds:

# Run the binary in the background, then check for listening ports or outbound connections
Start-Process -FilePath ".\marksman.exe" -ArgumentList "--server" -NoNewWindow -PassThru
Start-Sleep -Seconds 3
netstat -ano | Select-String "marksman|ESTABLISHED" | Select-Object -First 10
Stop-Process -Name "marksman" -Force

If I see a connection to an IP that isn't the project's own domain, I'm immediately suspicious. This isn't paranoia—I've caught a malicious "supply chain" incident this way, where a legitimate project's release was replaced with a trojan that dialed out to a command-and-control server. The download page looked perfectched, the hash matched the checksum file, but the checksum file itself was compromised. The only way to catch that is behavioral testing.

The Fifth Pass: What the Download Page Doesn't Say

The download page for Marksman lists the release date, the version, and the file sizes. It doesn't tell you:

• That the binary was built with --release optimizations, or if it's a debug build that's 3x slower.
• Whether the maintainer tested it on Windows 10 21H2 or only on Windows 11 24H2.
• Whether the portable zip includes the marksman.exe config file, or if you need to create it manually.

I've learned to check for the .exe.config file in the zip. If it's missing, the binary might not run at all on systems with strict execution policies. I also check the file timestamps inside the zip. If the .exe timestamp is months older than the zip's creation date, that means the maintainer just re-zipped an old build. That's not necessarily bad, but it means the "2026-02-08" date on the download page is a lie—the actual build is older.

Related resource

For a practical, community-maintained catalog of Windows software with proper release metadata, I recommend checking out GitVaults. It's where I found this Marksman release, and the page structure forced me to look at the right things. The specific entry I used is here: artempyanykh marksman 2026 02 08. The page includes the manifest and checksums directly, which is more than many official project sites do.

Caveat

I've written this based on my own experience, but Windows packaging is a moving target. If you spot an error—maybe my PowerShell hash comparison is too naive, or you know a better way to verify a signature on Windows—please correct me. I'd rather be wrong publicly than silently keep using a flawed process.