Compose hash computed on raw bytes, not canonicalized JSON #550

The compose hash computation in dstack/vmm/src/app/qemu.rs and dstack/dstack-util/src/system_setup.rs runs SHA-256 over the raw file bytes of app-compose.json rather than a canonicalized form, so semantically identical JSON documents with different whitespace or key ordering produce different hashes.

Root Cause

The compose hash is computed as SHA-256(raw_file_bytes) of the app-compose.json file. This means that semantically identical JSON documents with different whitespace, key ordering, or Unicode normalization produce different hashes. The VMM and guest both compute the hash this way, so any byte-level difference breaks attestation verification even if the configuration is functionally identical.

dstack issue #411 acknowledges this problem; no fix has been implemented.

Attack Path

1. Operator reformats app-compose.json (e.g., a tool normalizes whitespace or reorders keys)
2. The compose hash changes despite no semantic change to the configuration
3. Attestation verification fails because the expected hash no longer matches
4. Operator may be tempted to disable or weaken hash verification to work around the issue
5. Conversely, an attacker who can inject semantically different but byte-identical-hash JSON (hash collision) could bypass verification — though SHA-256 collision resistance makes this impractical

Impact

Primarily an operational reliability issue. Legitimate configuration changes that don't affect semantics break attestation. This creates pressure to weaken verification or maintain exact byte-level copies of compose files across all infrastructure.

Suggested Fix

Canonicalize JSON before hashing using a deterministic serialization format (e.g., JCS — JSON Canonicalization Scheme, RFC 8785):

let canonical = jcs::canonicalize(&compose_json)?;
let hash = Sha256::digest(&canonical);

Note: This issue was created automatically. The vulnerability report was generated by Claude and has not been verified by a human.