security

The whole workflow: hash-verify a download end to end

From vendor page to first launch: PowerShell, an explicit compare, and the policy that makes mismatches a hard stop. Short, boring, permanent.

ProofTune Project··4 min read
Security & trust illustration Security & trust

The ceremony in four lines

terminal / powershell
$expected = '021c5ca3…'   # copied from the release page
$actual   = (Get-FileHash .\ProofTune-0.1.0-preview.1-win-x64.msi).Hash
if ($actual -ieq $expected) { 'MATCH — safe to evaluate' }
else { 'MISMATCH — delete, redownload from source' }

Uniform discipline beats clever edge cases

  • Compare case-insensitively (-ieq) — hex is presentation; capitalization is not evidence.
  • Never eyeball prefixes: “starts with 021” is not a comparison; mashup pages count on prefix-readers.
  • Treat the comparison as a gate: if the “false” branch is “try anyway,” you don't have a verification step; you have punctuation.

Public-key-signature design would name the publisher too — for unsigned previews, the hash is the publisher claim. Why this preview ships unsigned describes the economic trade-off honestly instead of wishing it away.

ProofTune ProjectEngineering notes — every claim here names the bytes a real tool touches. Verify first, install second.
ProofTune logo

See these exact settings inside the real tool

The browser replica runs the same strings and states as the installed app — click around before you ever install anything.