Evidence
Hash verification
How a sealed package proves it has not changed: fingerprints, what a verification checks, how to verify a download yourself, and what a failure means.
Last revised
A fingerprint is only useful if the same package always produces the same fingerprint and a different package never does. MapProtector fingerprints the manifest and every attached file with SHA-256 in a form that is stable over time, so the bytes you download today verify against the seal for as long as you keep the package.
What a verification checks
Verification recomputes and compares. It repairs nothing — a verifier that “fixed” a hash it found wrong would turn the one control that can detect tampering into a mechanism that launders it.
| Check | What it compares |
|---|---|
| The manifest | The manifest as stored and as shown on screen, against the sealed fingerprint. |
| Each attached file | The stored file against its sealed fingerprint. |
| The set of files | That every sealed file is still present, and that nothing has been added since sealing. A missing file is a failure, not a warning; an unexpected one is too. |
Every check runs, even after one fails, so one verification gives the whole picture.
Running a verification
- Open the package and choose Verify integrity (Compliance Manager and above).
- Read the banner: verified means the manifest and every asset still hash to the sealed values; failed means something differs, and the integrity section names what.
- Each verification is recorded permanently with its outcome, and verified and failed are separate audit actions, so “has any package ever failed a check” is answerable by filtering rather than by reading.
Verifying outside MapProtector
Download the manifest and compute its SHA-256 with any standard tool; compare it with the fingerprint shown on the package. The bytes you download are the bytes that were fingerprinted. See Downloads.