search

gittuf / gittuf

A security layer for Git repositories
https://gittuf.dev
Apache License 2.0
439 stars 28 forks source link

Remove TUF fields that don't apply to gittuf #415

Closed adityasaky closed 4 weeks ago

adityasaky commented 1 month ago

The original root and targets metadata schemas were taken directly from the TUF specification. As such, they include fields that we don't use in gittuf.

Removed Fields:

  1. SpecVersion: this field identifies the version of the TUF specification the metadata conforms to. We don't conform to the TUF specification.

  2. ConsistentSnapshot: this boolean field indicates if the repository uses consistent snapshots as defined in the TUF specification. We don't use this (and in fact we don't use snapshot metadata at all as the RSL effectively serves the snapshot role).

  3. Version: this field is an incrementing integer that identifies the version of the metadata for the specific role. In TUF, this is used to ensure we have a consistent set of metadata via the snapshot role. As before, the RSL gives us this property naturally.

Note that we still don't use the Expires field in gittuf verification. We need to explore what it means for policy metadata to expire in a Git repository and whether the expiry check (for the latest policy metadata) applies the same way it does in TUF.

adityasaky commented 1 month ago

cc @lukpueh

JustinCappos commented 1 month ago

Conceptually, this makes sense to me.

On a related note, I do wonder if having a version field for this information is useful, but maybe that should be somewhere for the overall gittuf metadata / file formats.

adityasaky commented 1 month ago

You're right in that we'll need some way of tracking the gittuf implementation version that some piece of metadata was generated / updated with, possibly only when there's an actual breaking change. We see it with 3418e74eb4a7b4f6c5ac32a7653a6b22cd59b8cb (draft commit to add role name to targets metadata so we sign over it) and also in #326 but I want to address how that works separately. I think we'll want to do something like track the versions for which the tuf package in the implementation makes a backwards incompatible change?