fix(data): add back SnapshotFileMeta.Custom

[arbll]

Adds back a Custom field to SnapshotFileMeta following its removal in #345.

Release Notes: Add back a Custom field to SnapshotFileMeta

Types of changes:

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Description of the changes being introduced by the pull request:

We rely on this Custom field to store some custom data related to delegated targets. The removal of this field would force us to store this outside of the signed TUF file or in a hacky map in Snapshot.Custom.

Please verify and check that the pull request fulfills the following requirements:

• Tests have been added for the bug fix or new feature
• Docs have been added for the bug fix or new feature

[trishankatdatadog]

I'm not strictly against this PR, but a few things:

1. Why just Snapshot? Why not the base Metadata itself, while we are it?
2. I don't think we should keep indefinitely supporting this custom (pun intended) use case. If we add this back, we should add a deprecation notice to observe that we can remove this later.

[asraa]

Thanks @arbll!

As with @trishankatdatadog, this field is not in the TUF specification: https://theupdateframework.github.io/specification/latest/#file-formats-snapshot

If you want to keep information about a delegated target, then ideally the information should live in/signed by the parent role, rather than the snapshot role, correct?

It seems like you may want CUSTOM metadata inside a DELEGATIONS object long-term, right? https://theupdateframework.github.io/specification/latest/#delegations

I'm on the side of adding this specifically to SnapshotFileMeta, and not to the base FileMeta that TimestampFileMeta uses, I'd rather scope this usage minimally.

[trishankatdatadog]

I'm on the side of adding this specifically to SnapshotFileMeta, and not to the base FileMeta that TimestampFileMeta uses, I'd rather scope this usage minimally.

Agreed. Is there a good way to make this optional and not built or at least included in the metadata (even as an empty field) by default?

[trishankatdatadog]

I'm on the side of adding this specifically to SnapshotFileMeta, and not to the base FileMeta that TimestampFileMeta uses, I'd rather scope this usage minimally.

I also want to make sure that we only need this kind of surgical addition, and not have additional PRs later adding this in other places.

[asraa]

not built or at least included in the metadata (even as an empty field) by default?

Should be omitted when empty! So I think this is good.

[trishankatdatadog]

Should be omitted when empty! So I think this is good.

I am worried about end-users getting confused about this custom addition, so we need to at least document why it's there.

[asraa]

Approval, but to accomodate, let's add a commend above type SnapshotFileMeta that it includes Custom.

Don't think end-users will even see the field if it isn't populated, but worth a comment

[trishankatdatadog]

Approval, but to accomodate, let's add a commend above type SnapshotFileMeta that it includes Custom.

Don't think end-users will even see the field if it isn't populated, but worth a comment

@arbll pls make the change? thx!

[trishankatdatadog]

Thanks @arbll. Would you please:

1. Sign off DCO and rebase + force-push
2. Confirm that custom is not populated by default unless explicitly set?

[arbll]

@trishankatdatadog Done

[trishankatdatadog]

I'm not crazy about this PR (we should add a deprecation notice and figure out alternatives), but happy to unblock for now.