sigstore: use our own Statement type #930
Conversation
Signed-off-by: William Woodruff <[email protected]>
Signed-off-by: William Woodruff <[email protected]>
Signed-off-by: William Woodruff <[email protected]>
| ) | ||
|
|
||
|
|
||
| class _StatementBuilder: |
There was a problem hiding this comment.
NB: We will probably want to make this API public at some point, but not yet (it needs more design consideration).
| except ValidationError as e: | ||
| raise ValueError(f"invalid statement: {e}") | ||
|
|
||
| return Statement(stmt.model_dump_json(by_alias=True).encode()) |
There was a problem hiding this comment.
A consideration here: technically we make no canonical/serialization guarantees other than "it's valid JSON", but we could do RFC 8785 for good measure here.
Signed-off-by: William Woodruff <[email protected]>
Signed-off-by: William Woodruff <[email protected]>
Signed-off-by: William Woodruff <[email protected]>
woodruffw
added
component:signing
Signed-off-by: William Woodruff <[email protected]>
Logger objects are not part of the public API. Signed-off-by: William Woodruff <[email protected]>
Signed-off-by: William Woodruff <[email protected]>
Signed-off-by: William Woodruff <[email protected]>
| return Statement(stmt.model_dump_json(by_alias=True).encode()) | ||
|
|
||
|
|
||
| class Envelope: |
There was a problem hiding this comment.
Added this as a thin wrapper for sigstore_protobuf_specs.io.intoto.Envelope, so that we don't leak a protobuf model into the public API here.
There was a problem hiding this comment.
Code looks good to me. I'm not too familiar with in-toto but since the signing is essentially still experimental/private API (because _StatementBuilder and _Statement are private and CLI does not expose this) seems fine to merge.
Are there conformance tests for statement bundles already?
Should we have a full round trip test with both sign & verify for the statement bundle?
I believe so, but we currently xfail them because we only support signing, not verifying. Once this is merged I can work on verification support.
Yep, I'll do this with the aforementioned followup 🙂 |
This solves our "which serialization is right" problem with DSSE by replacing our use of
in_toto_attestationwith our ownStatementtype, which is surfaced to the user as an opaquebytescontainer but ensures (internally) that the JSON object structure is as expected.Long term, we'll probably want to reintroduce
in_toto_attestationas a dep in some form, but keep ourStatementas the public API type for interface stability reasons.