Add a higher level API.

[mihaimaruseac]

Summary

Currently, this only supports Sigstore (and only DSSE on verification). I want to push this now so that people can start playing with it while I update the Colab demo and try to make the API more uniform and add support for the missing cases.

With this, the default signing should be as simple as

from model_signing import api as model_signing_api

model_signing_api.sign(model_path, signature_path)

And verification would be as simple as:

from model_signing import api as model_signing_api

model_signing_api.verify(
  model_path, signature_path,
  expected_identity, expected_oidc_provider
)

Will think on how to simplify this even further..

This is part of #172, but not yet closing it

Release Note

NONE

Documentation

NONE

[spencerschrock]

Will think on how to simplify this even further.

I think the main thing that stands out to me now is that Signing/Verifying is a high level wrapper that tends to be simple, but the devil is in the Hashing details. The HashingConfig seems like a copy of the serialization API.

I assume the aim is to be explicit about what is backwards compatible by semver? Either way that seems like the rough point to me currently.

[mihaimaruseac]

I think the main thing that stands out to me now is that Signing/Verifying is a high level wrapper that tends to be simple, but the devil is in the Hashing details.

That is true. For most usecases, the config should not be used to change anything from the defaults, but we want to allow flexibility.

The HashingConfig seems like a copy of the serialization API.

I'm planning to make it even more uniform in the future, having setters for each field and then a verification method just before the first signing event. But for that I'd first need to make the serialization API more uniform.

I assume the aim is to be explicit about what is backwards compatible by semver? Either way that seems like the rough point to me currently.

Yup. We can then change anything else in the library and as long as these methods have the same interface no user would be broken. In fact, probably we should make everything else private (but need to check with documentation, so let's do this only after we have all documentation done).

[spencerschrock]

I'm planning to make it even more uniform in the future

As we iterate here on the stable API, what's the convention in PyPI? Anything under 1.0 can expect breaking changes?

[mihaimaruseac]

Anything under 1.0 can expect breaking changes?

Yeah, we'll follow https://semver.org/#semantic-versioning-specification-semver

Thank you for the review!