Evidence
Hash verification
How a sealed package proves it has not changed: canonical serialization, SHA-256 fingerprints, what a verification checks, and what each 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 guarantees the first by serializing the manifest canonically before hashing it, and the second by refusing to hash anything it cannot represent exactly.
Canonical serialization
- Object keys are sorted, so two manifests with the same facts produce the same bytes whichever process assembled them.
- Money is carried as a decimal string of minor units, never a floating-point number, so a fingerprint cannot change with a runtime upgrade.
- A missing value is spelled
null. A field cannot silently vanish from the hash by being undefined. - A value that cannot be represented exactly is refused rather than approximated.
The fingerprint is the SHA-256 of those bytes. Each attached asset is fingerprinted from the bytes actually stored.
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 |
|---|---|
| Stored manifest object | The bytes stored at sealing, hashed again, against the sealed fingerprint. This is what an outside reader would be handed. |
| Manifest row | The manifest re-serialized from the database, against the same fingerprint. This is what every screen renders from. |
| Object and row agree | The two representations against each other. A divergence is a failure even when one still matches the seal. |
| Each asset | The stored bytes against the sealed asset fingerprint. |
| Asset set | That every sealed asset is still retrievable, and that no asset exists that was not sealed. A missing asset 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. Because the manifest is canonical, the bytes you download are the bytes that were hashed. See Downloads.