Add more workflow information for Github workflow certificates (sha, run) about fulcio HOT 9 CLOSED

@laurentsimon FYI

from fulcio.

Would it be useful to have a provider-agnostic extension?
Say we have Google and GitHub providers. Depending on context, we may want to add additional information (in the case of this issue, a commit hash): will the OID have a {provider type, datablob} structure?
I don't think we want to create a new extension every time a provider needs to add additional context to the cert.
wdut?

from fulcio.

Would it be useful to have a provider-agnostic extension?

Yeah that's doable -- we just have a prefix reserved (1.3.6.1.4.1.57264), and we can start using them as we please!

Right now Bob's planning on using 1.1 for issuer context, provide-agnositc. I'm not sure how conventions work here. should 1.2 be commit sha and 1.3 be trigger? or should they be bundled in some way?

from fulcio.

cc @bobcallaway

from fulcio.

Or barring privacy concerns around logging the full github token in rekor (are there any? maybe private workflows?) maybe we can serialize the whole token and stick it in a single extension?

from fulcio.

yeah that's what I was thinking too: version || len_provider_name || provider_name || provider_version || len_serialize_data || serialized_data. provider_version probably not necessary.

from fulcio.

Side note: @dlorenc got the same effect as this by signing with annotations on the sha/commit.

I think it's still useful to have this information in the cert in case it's not a cosign container sig being created (just a signature on an artifact, and this info can come from the cert)

from fulcio.

@asraa Good to close this issue as fixed?

from fulcio.

Yes! Fixed

from fulcio.