Add provenance to target custom metadata

[kipz]

It's sometimes the case that I'd like to verify the provenance of an artifact in TUF.

Currently this information is lost, at least when using tuf-on-ci and no other attestations exist for the artifact (e.g. in-toto). I think this is pretty common for tuf-on-ci use cases.

One solution for tuf-on-ci would be to include some provenance (e.g. repo, workload identity, commit) in the target's custom metadata field. TUF provides a facility for that: https://theupdateframework.github.io/specification/latest/#targets-obj-targets which seems appropriate.

If there's appetite for something like this, I'd be happy to open a PR.

[jku]

I have been thinking about something like this as well... I'm not opposed but also not completely sure about it:

• like I've mentioned I don't want features without a real use case and a user -- the complexity is high enough already
• custom metadata is not always obviously better than just additional artifacts: we can't expect all TUF client libraries to support our custom metadata so application needs to handle the custom data anyway -- so it could just download the additional artifact with the same amount of code (while keeping tuf-on-ci simpler)
• Especially if the attestation is not from tuf-on-ci workflow but e.g. a build process that produces the artifact, it feels like this attestation could be just another artifact?
• If we think about attestations related to tuf-on-ci workloads themselves, the workload identity would likely be signing-event... which essentially runs on PRs (only on upstream branches but still). It can make an attestation but somehow feels less useful when we don't even know if it will be merged
• One "real" attestation time feels like snapshot to me -- this is when the workflow could really attest that "a new repository snapshot has been created and it was done with workflow X by runner Y". I'm not sure how this could be used in a TUF ecosystem though

If there's appetite for something like this, I'd be happy to open a PR.

I'd be interested in hearing the use case in more detail -- what exactly are we attesting and how do we expect the attestation to be consumed?

[jku]

I'll also mention a vaguely related idea:

I've been thinking about publishing an event stream of repository actions: send an entry to a transparency log every time the repository makes some significant change (like new root, timestamp or snapshot)

I've not done anything about that either because the use case seems rather vague as well: Who monitors this log? What is an actionable log event?

[kipz]

• like I've mentioned I don't want features without a real use case and a user -- the complexity is high enough already

Of course! Our use case is about discovering and using the provenance of target artifacts (trust policy related stuff) that are added to the TUF GitHub repo and using those data to generate downstream attestations, but what you say below about how it should really be a tuf-on-ci attestation (i.e. signed by the workload) makes more sense, and doesn't really fit with TUF. Also, your point that an upstream provenance attestation is more meaningful (assuming the TUF GitHub repo isn't the source of truth for anything), and could be added to TUF targets, but that has nothing to do with tuf-on-ci.

I think there's still something we (tuf/in-toto) ecosystem needs here. I just wish I had more of the Git semantics in TUF :)

I've been thinking about publishing an event stream of repository actions: send an entry to a transparency log every time the repository makes some significant change (like new root, timestamp or snapshot)

I've not done anything about that either because the use case seems rather vague as well: Who monitors this log? What is an actionable log event?

100% agree re: transparency log. Unless someone can/will monitor it and can actually take some action based on something being there (or not), then it's not clear how useful it is.

Thanks for your review. I'll close for now and think about this some more!