Extending shard.lock with cryptographic signatures after Crystal 1.0.0

The shard.lock file currently records exact dependency versions and checksums, allowing reliable backup and integrity verification via shards check. With Crystal 1.0.0 introducing deterministic lock‑file generation, the community is considering whether the lock file should also store a cryptographic signature of each dependency tarball to strengthen supply‑chain security.

Adding such signatures must remain compatible with older Crystal releases that may ignore unknown fields, ensuring they do not break existing workflows or cause silent fallback to weaker verification. The design must also preserve deterministic generation so that identical shards.yml produces the same lock file across machines, and any new verification step should integrate cleanly with existing commands.

What format should the signature field take within the lock file? How should older Crystal versions treat the new field to avoid verification gaps? Should a new subcommand (e.g., shards verify-signature) be introduced, or should shards check be extended to validate signatures?