theupdateframework / theupdateframework/specification

How do we initialize trust with local metadata, and no access to a remote repository?

Open
#108 3 comments 1 reaction 0 assignees View on GitHub

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.EXT though.
  • 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 as FILENAME.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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.