theupdateframework / theupdateframework/specification
How do we initialize trust with local metadata, and no access to a remote repository?
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 405
- Forks
- 59
- Avg merge
- 3d 4h
- Merged PRs (30d)
- 1
Description
On Fuchsia, we are using TUF not only to fetch new packages, but also as a file system implementation to launch packages (see this for more details). For a long time, we've been using ephemeral repositories for package resolution, so we've always needed to be online. However we're finally starting to explore how we'll resolve packages when we've rebooted and we're not able to go online.
While scoping out this work, I noticed the spec is actually a little vague as to how we should initialize trust when we have a local cache of TUF metadata, but no way to fetch remote metadata:
- In section 5.1, I don't actually see where we are supposed to persist any root metadata changes. Presumably we'd write these files as
$ROOT_VERISON.root.EXTthough. - In section 5.2, we write the timestamp metadata as
timestamp.EXT. It'd be easy enough to load that file since we expect that file to be unversioned, but... - In section 5.3, we write the snapshot to
snapshot.EXT. Likewise, 5.4 we write targets and delegates asFILENAME.EXT.
We use consistent snapshots, so just trying to search the local store first will fail, because we'll be looking for $SNAPSHOT_VERSION.snapshot.EXT and $TARGETS_VERSION.snapshot.EXT. Should we initialize trust by disabling consistent snapshots, trying to load all the local metadata, then re-enabling consistent snapshots? I think that ought to work, but the one sticking point is how to handle a partial update (see https://github.com/theupdateframework/specification/issues/69). In that case, presumably the initialization should succeed, just not initialize the TUF database with the inconsistent metadata. To protect against this, presumably we ought to write metadata to the local store in a transaction.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with specification sections 5.1–5.4 and the partial-update discussion in issue 69. Trace how root, timestamp, snapshot, targets, and delegated metadata are persisted and loaded from the local store. Done means the specification clearly defines offline trust initialization, consistent-snapshot handling, and safe behavior for partial updates.
Written by the indexing model from the issue text.
Assessment
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100