Hayden B

If we're modifying the definition, I agree we should move it to the Sigstore package namespace. Don't feel incredibly strongly about this though, and to your second point, I'm not...

One way to look at this is to think about how you want the verifier to handle multiple artifacts in one bundle. Does the verifier fail if any artifact fails...

We have something like this in Fulcio for the file-based CA, for the signing certificate - https://github.com/sigstore/fulcio/blob/main/pkg/ca/fileca/fileca.go#L34 I would advise against this though. It requires adding locks throughout the codebase....

Closing this out, as this can be managed outside of the service.

I am not familiar with Vault deployments, but if the vault and key is accessible locally, you can specify the key starting with `hashivault://`. You'll also need to disable ntp...

Everything you’ve done seems correct. Are you able to inspect the tsq and tsr with OpenSSL?

What's the hashing algorithm used with the key? One guess is if it's not sha256, then it'll fail. Everything you've specified seems correct, so you might need to step through...

Seems like a nice to have - Does the golang openapi generators have support for http2? http2 is also experimental currently in the core library (https://pkg.go.dev/golang.org/x/net/http2)

As a meta comment, I'm not sure how we expect URI to be used. If this is just for logging purposes, then best effort population of the URI seems sufficient....

> I could imagine someone creating a policy that checked the URI in the verification result. I think this would be OK, though I'd rather see policies around only around...