Digest subcommand

[puerco]

Summary

This PR adds a digest subcommand to the model_signing CLi. This allows other tools to find out the computed digest of a serialized model directory. It uses the same serializer as the sign command and supports adding files to the ignore list.

[puerco@babieco model-transparency] on  digest-subcommand 🐍 [venv]❯ python -m model_signing digest --help
Usage: python -m model_signing digest [OPTIONS] MODEL_PATH

  Computes the digest of a model.

  The digest subcommand serializes a model directory and computes the "root"
  digest (hash), the same used when signing and as the attestation subject.

  By default, git-related files are ignored (same behavior as the sign
  command). Use --no-ignore-git-paths to include them. To ignore other files
  from the directory serialization, use --ignore-paths.

Options:
  --ignore-paths IGNORE_PATHS     File paths to ignore when signing or
                                  verifying.
  --ignore-git-paths / --no-ignore-git-paths
                                  Ignore git-related files when signing or
                                  verifying.  [default: ignore-git-paths]
  --allow_symlinks                Whether to allow following symlinks when
                                  signing or verifying files.
  -h, --help                      Show this message and exit.

Checklist

• [x] All commits are signed-off, using DCO
• [x] All new code has docstrings and type annotations
• [ ] All new code is covered by tests. Aim for at least 90% coverage. CI is configured to highlight lines not covered by tests.
• [x] Public facing changes are paired with documentation changes
• [x] Release note has been added to CHANGELOG.md if needed

Closes https://github.com/sigstore/model-transparency/issues/565

[ralphbean]

As a user, I see the value in getting just the root hash. I would use it for the Subject of other attestations.

Outputting all the hashes in the manifest would only be valuable to me in helping explain and understanding what the tool has done. The serialization field would be necessary too, if all the resources are also necessary.

[mihaimaruseac]

That makes sense. What about displaying just the root hash by default, but if the user passes a --full flag we return a json that contains all the hashes and the serialization field?