Repository navigation
Adopt RFC 8785 (JCS) for canonical compose hash calculation #411
Description
Problem
Right now, the same appcompose can hash differently depending on how the JSON is formatted - whitespace, key order, indentation, you name it. This makes verification a pain for devs trying to prove their docker-compose is actually running in a TEE.
Proposal
Use RFC 8785 - JSON Canonicalization Scheme for compose hash calculation.
Rollout
Phase 1 - SDK & Docs
- Add JCS hash calculation to the SDK
- Update docs explaining how it works and how the compose hash is built from each component
- No breaking changes yet
Phase 2 - Migration
- Make JCS the default in SDK
- Provide tooling to verify/convert existing files
Phase 3 - Enforcement
- Require JCS-canonical hashes in a future release
- Reject non-canonical submissions
Separate hashes for docker_compose & prelaunch_script
These two should have their own hashes, not just be buried in the final compose hash. Makes debugging way easier - you can tell exactly which part changed when hashes don't match. Plus they're raw strings (YAML/bash), so they don't go through JCS anyway. Keeping them separate gives better traceability.
Activity
h4x3rotab commentedon Jun 30, 2026
Maintainer triage update: this remains open intentionally and is listed separately from vulnerability reports in the security roadmap/hardening table: https://github.com/Dstack-TEE/dstack/blob/master/docs/security/public-security-reports.md#related-security-roadmap-and-hardening
Disposition: measurement roadmap. A future canonical hash scheme may still be useful. Current raw-byte hashing is intentional and is recorded in #550.