Jason Hall

There is some work in progress to cache and reuse certificates, here: https://github.com/sigstore/gitsign/tree/main/cmd/gitsign-credential-cache There are some noteworthy caveats and limitations at this time, but it's actively being worked on by...

A Chrome extension is an interesting approach. I'd have to think about how it would cache things in a place the `gitsign` (or `cosign`) executables could get to them, but...

> @imjasonh I'd be happy to give it a try and let you know the feedback. Please let me know what branch/tag version I should be using. You can try...

It's definitely possible, but I wonder how you'd anticipate using it. Can you give some more detail about your use case?

I really like the general direction of this change. I don't have any good naming suggestions but I'll keep thinking about it. While we're making this change, do we think...

Oh I don't have a strong opinion or any signal either way. I just thought while we're changing the API we can take the opportunity to reassess other decisions if...

@rakhbari What types of non-Tekton resources are you creating using Triggers?

Yeah, `ko`'s probably a bad example, since it can produce tarballs, and even load directly into KinD all by itself. I don't know of any tools off the top of...

Looks like we do a bunch of validation that the key exists, and cache it with a TTL, and that's why we `Get` it instead of just using it. https://github.com/sigstore/sigstore/blob/845467ef3d8df5ab991f5ecf3a5f4aac747a9f14/pkg/signature/kms/gcp/client.go#L177

SGTM, I can update my PRs so that sigstore/sigstore's `fulcioroots.Get` doesn't consult the env var, and only cosign's usage of it does, with comments indicating the difference, and that callers...