Hayden B

Ah, sorry, I see where my confusion is. I was conflating libraries/gems with applications. I was referring to maintainers checking the lockfile into a source repository for applications. Users who...

Hey, thanks for the suggestion. Per https://github.com/sigstore/sigstore/blob/main/POLICY.md#kms-providers, if there is significant community interest in this, then we would accept this. I'll leave this issue up for any discussion.

> repository could publish keys/certs for verifiers X weeks (timestamp expiry period) before they are made available to signers -- e.g. fulcio cert could be added in the metadata before...

Are these equivalent identifiers? The former is a specific "builder" identity. This aligns to SLSA's model for identity, that trust is rooted in the builder. In terms of trust boundary...

For supporting a private Sigstore deployment, I agree that long-term, providing a trusted root file seems like a good solution. Short term, can we make the TUF repository configurable with...

Verification policy is what values are expected in a certificate. For a Fulcio certificate, we mandate checking the subject alternative name and a custom OID for the OIDC issuer. For...

> sigstore-python provides an API for verification that takes in a PublicKey or a trusted_root option. Option A: This verification only performs a signature verification. Option B: This verification does...

> SCT verification may need to be disabled. Maybe via trusted root config? This seems like a reasonable feature. There will be private deployments that don't need transparency, eg the...

We had thought about something similar in protobuf-specs, so we could reuse it there. If this is a significant amount of work though, just manually configuring it (with documentation ideally...

The closest analogy in Cosign would be the `cosign attach` commands that upload detached metadata to a container in a registry. We're just starting to add bundle support in Cosign,...