Statement rejects the in-toto framework's git digest types (gitCommit/gitTree); would you take an opt-in?

[DrVelvetFog]

Statement validates subjects against Digest = Literal["sha256", "sha384", "sha512", "sha3_256", "sha3_384", "sha3_512"] (sigstore/dsse/__init__.py), so a statement whose subject uses the git digest types the in-toto framework defines — gitCommit, gitTree, gitTag — is rejected as malformed. The unknown key itself is the rejection, so adding a sha256 alongside doesn't help.

Repro on 4.5.0:

import json
from sigstore.dsse import Statement

stmt = {
    "_type": "https://in-toto.io/Statement/v1",
    "subject": [{"name": "example", "digest": {"gitTree": "4b825dc642cb6eb9a060e54bf8d69288fbee4904"}}],
    "predicateType": "https://example.com/predicate/v1",
    "predicate": {},
}
Statement(json.dumps(stmt).encode())   # sigstore.errors.Error: malformed in-toto statement

The same statement with {"sha256": ...} is accepted; with both keys it's rejected again.

I know the restriction is deliberate — #1018 keeps the default set aligned with Sigstore's algorithm registry, and git digests are SHA-1-shaped, which is exactly what it excludes. I'm not asking to widen the default. But statements about git objects are a real category (the framework defines the types, and SLSA's source track lives on them), and right now the only way to sign one with this library is to give up the DSSE envelope and sign the statement bytes as an artifact — which keeps key custody and identity binding but loses the typing for everyone downstream.

Would you take an opt-in that leaves the default untouched? Something like Statement(..., allow_unregistered_digests=True), or a laxer parse mode on the verify side. If some shape here sounds acceptable I'm happy to write the PR.

(Related: once #1846 ships, the rejection at least names the offending field; this issue is about accepting it.)

[woodruffw]

Do you have an actual use case for this, namely one that's relevant to Sigstore itself?

And note: please respond with your actual words, please do not use an LLM to communicate on issues.

[DrVelvetFog]

Do you have an actual use case for this, namely one that's relevant to Sigstore itself?

And note: please respond with your actual words, please do not use an LLM to communicate on issues.

yeah, I maintain a GitHub Action that attests code review coverage, on every merge it signs an in-toto statement whose subject is the git tree that shipped ( the predicate is in-toto/attestation#581 ). Right now I sign the statement bytes as plain artifacts because Statement rejects the git tree digest, works alright, but loses the DSSE typing for anything downstream.

Gittuf already does this same class of statement on the Go side so the pattern exists, it's just not reachable from the Python clients typed path.