search

sigstore / sigstore-python

A Sigstore client written in Python
https://pypi.org/p/sigstore
Other
220 stars 42 forks source link

Convert in-toto `Statement` to Sigstore DSSE Statement via a single call #1076

Closed mihaimaruseac closed 1 month ago

mihaimaruseac commented 1 month ago

Description

For model signing, we're producing in-toto statements for serialization of a model (e.g., https://github.com/sigstore/model-transparency/pull/266 -- if looking at it before merging, look at the last commit only). When signing, we need to convert in-toto Statements to Sigstore Statements

One option is to serialize the in-toto one to bytes and then use the Sigstore one's constructor to unparse. But this requires too much data transformations to and from strings, so I'd avoid it if possible.

The other is to use _StatementBuilder. But this is private -- not a big issue, we could make it public. But, it still dumps a json to then pass the results to the constructor.

What I'd like to propose is a classmethod on Statement that would just convert directly from in-toto Statement, if that would be possible.

woodruffw commented 1 month ago

What I'd like to propose is a classmethod on Statement that would just convert directly from in-toto Statement, if that would be possible.

To make sure I understand: this would require a dependency on in_toto_attestation, correct? I'm wary of that for two reasons:

  1. I've been trying to reduce the number of third-party types in public APIs, in part because it's hard to assert SemVer guarantees around foreign types withoutn strictly pinning sigstore-python's dependencies (which makes it hard to integrate into pre-existing dependency sets).
  2. in_toto_attestation currently depends on protobuf, meaning that this would leave sigstore-python with two different Protobuf library implementations in its codebase (protobuf and betterproto). I'm slowly working on getting rid of betterproto as well, since IME Protobuf libraries tend to be poorly impedance matched to modern Python idioms (and result in similar foreign-type-in-public-API problems).

If it works for your use case, I think what I'd prefer to do is make _StatementBuilder a public API (experimental for the current release series, and then stable with 4.x if there are no significant problems) and work on reducing the number of serialization round-trips it does (which we can do with a private _Statement -> Statement constructor). Do you think that would work well for you?

mihaimaruseac commented 1 month ago

That would work quite well, thank you. I just wanted to be able to reduce the round trips to json/bytes. Any format that works the best for the library is best for us too.

Thank you!

woodruffw commented 1 month ago

Sounds good! I'll look into making those APIs public tomorrow.

woodruffw commented 1 month ago

Opened #1077 for this, PTAL 🙂