Jason Hall

Yeah that's more or less what I was envisioning. Since it's possible without modifying ko (though imperfectly) and not very clear how it would work in ko's UX, I'm inclined...

I don't think there are enough signed base images in the wild yet to justify failing closed. A big scary warning sgtm though. Since we control the default and the...

Taking a stab at the latter two points: .ko.yaml: ```yaml verifySignatures: "alpine:1.23": - publicKey: https://some.url/path/to/key.pub annotations: key: value another: value2 ``` If any image is based on `alpine:1.23` then `ko`...

Except for `ko` version, this information is already embedded in the Go binary and now available via `ko deps`. It's nice that different versions of `ko` produce the same image...

> Would it be bad to put the `ko` version here: https://github.com/google/go-containerregistry/blob/40ba044ce038467e87299d229dcae9f5b2ea815f/pkg/v1/config.go#L34 Doesn't really matter to me where we put it, so long as we can document the expectation of...

I wasn't thinking that exactly but it would also e ~easy to support. What OCI annotations does the GitHub UI expect? `source` and `revision`?

This seems more related to https://github.com/google/ko/issues/366, which will happen some time after Go 1.18, and only be available to images built using Go 1.18. In the meantime, it looks like...

FWIW I tried to leverage MultiWrite in #238 and evidence suggested it was slower, since it required builds to finish before publishing. I would believe building all binaries at once...

#267 and #269 also have some promise to make builds faster, by caching outputs and avoiding unnecessary builds/pushes altogether. That might be another good area to investigate.

The cosign repo has a spec for specifying layered SBOMs: https://github.com/sigstore/cosign/blob/main/specs/SBOM_SPEC.md#scopes I'm not sure if anybody actually adheres to it today, either on the producing- or consuming-side. If we decide...