2018-01-25 22:11:32 +00:00
|
|
|
# Quickstart #
|
|
|
|
|
|
2019-04-04 21:14:13 +00:00
|
|
|
In this quickstart tutorial, we'll use the basic TUF command-line interface
|
|
|
|
|
(CLI), which includes the `repo.py` script and the `client.py` script, to set
|
|
|
|
|
up a repository with an update and metadata about that update, then download
|
|
|
|
|
and verify that update as a client.
|
|
|
|
|
|
|
|
|
|
Unlike the underlying TUF modules that the CLI uses, the CLI itself is a bit
|
|
|
|
|
bare-bones. Using the CLI is the easiest way to familiarize yourself with
|
2019-04-08 15:49:25 +00:00
|
|
|
how TUF works, however. It will serve as a very basic update system.
|
2018-06-25 15:53:59 +00:00
|
|
|
|
2018-06-26 21:21:07 +00:00
|
|
|
----
|
2018-01-25 22:11:32 +00:00
|
|
|
|
2019-04-08 15:49:25 +00:00
|
|
|
**Step (0)** - Make sure TUF is installed.
|
2019-04-04 21:14:13 +00:00
|
|
|
|
2019-04-08 17:32:43 +00:00
|
|
|
Make sure that TUF is installed, along with some of the optional cryptographic
|
2019-04-08 19:21:52 +00:00
|
|
|
libraries and C extensions. Try this command to do that:
|
2020-02-18 12:46:34 +00:00
|
|
|
`pip install securesystemslib[colors,crypto,pynacl] tuf`
|
2019-04-04 21:14:13 +00:00
|
|
|
|
2019-04-08 19:21:52 +00:00
|
|
|
If you run into errors during that pip command, please consult the more
|
|
|
|
|
detailed [TUF Installation Instructions](INSTALLATION.rst). (There are some
|
|
|
|
|
system libraries that you may need to install first.)
|
|
|
|
|
|
2019-04-04 21:14:13 +00:00
|
|
|
|
2019-04-08 15:49:25 +00:00
|
|
|
**Step (1)** - Create a basic repository and client.
|
2019-04-04 21:14:13 +00:00
|
|
|
|
|
|
|
|
The following command will set up a basic update repository and basic client
|
|
|
|
|
that knows about the repository. `tufrepo`, `tufkeystore`, and
|
|
|
|
|
`tufclient` directories will be created in the current directory.
|
|
|
|
|
|
2018-01-25 22:33:14 +00:00
|
|
|
```Bash
|
|
|
|
|
$ repo.py --init
|
|
|
|
|
```
|
|
|
|
|
|
2019-04-04 21:14:13 +00:00
|
|
|
Four sets of keys are created in the `tufkeystore` directory. Initial metadata
|
|
|
|
|
about the repository is created in the `tufrepo` directory, and also provided
|
|
|
|
|
to the client in the `tufclient` directory.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
**Step (2)** - Add an update to the repository.
|
|
|
|
|
|
|
|
|
|
We'll create a target file that will later be delivered as an update to clients.
|
|
|
|
|
Metadata about that file will be created and signed, and added to the
|
|
|
|
|
repository's metadata.
|
|
|
|
|
|
2018-01-25 22:33:14 +00:00
|
|
|
```Bash
|
2018-04-06 21:24:15 +00:00
|
|
|
$ echo 'Test file' > testfile
|
|
|
|
|
$ repo.py --add testfile
|
2018-06-26 21:07:33 +00:00
|
|
|
$ tree tufrepo/
|
|
|
|
|
tufrepo/
|
|
|
|
|
├── metadata
|
|
|
|
|
│ ├── 1.root.json
|
|
|
|
|
│ ├── root.json
|
|
|
|
|
│ ├── snapshot.json
|
|
|
|
|
│ ├── targets.json
|
|
|
|
|
│ └── timestamp.json
|
|
|
|
|
├── metadata.staged
|
|
|
|
|
│ ├── 1.root.json
|
|
|
|
|
│ ├── root.json
|
|
|
|
|
│ ├── snapshot.json
|
|
|
|
|
│ ├── targets.json
|
|
|
|
|
│ └── timestamp.json
|
|
|
|
|
└── targets
|
|
|
|
|
└── testfile
|
|
|
|
|
|
|
|
|
|
3 directories, 11 files
|
2018-01-25 22:33:14 +00:00
|
|
|
```
|
2019-04-04 21:14:13 +00:00
|
|
|
|
|
|
|
|
The new file `testfile` is added to the repository, and metadata is updated in
|
|
|
|
|
the `tufrepo` directory. The Targets metadata (`targets.json`) now includes
|
|
|
|
|
the file size and hashes of the `testfile` target file, and this metadata is
|
|
|
|
|
signed by the Targets role's key, so that clients can verify that metadata
|
|
|
|
|
about `testfile` and then verify `testfile` itself.
|
|
|
|
|
|
2018-01-25 22:33:14 +00:00
|
|
|
|
2019-04-08 15:49:25 +00:00
|
|
|
**Step (3)** - Serve the repo.
|
2019-04-04 21:14:13 +00:00
|
|
|
|
|
|
|
|
We'll host a toy http server containing the `testfile` update and the
|
|
|
|
|
repository's metadata.
|
|
|
|
|
|
2018-01-25 22:33:14 +00:00
|
|
|
```Bash
|
2018-01-30 17:20:21 +00:00
|
|
|
$ cd "tufrepo/"
|
2019-04-04 21:14:13 +00:00
|
|
|
$ python3 -m http.server 8001
|
|
|
|
|
|
|
|
|
|
# or, if you are using Python2:
|
2018-01-25 22:33:14 +00:00
|
|
|
$ python -m SimpleHTTPServer 8001
|
2018-01-26 16:39:27 +00:00
|
|
|
|
2018-01-25 22:33:14 +00:00
|
|
|
```
|
|
|
|
|
|
2019-04-04 21:14:13 +00:00
|
|
|
**Step (4)** - Obtain and verify the `testfile` update on a client.
|
|
|
|
|
|
|
|
|
|
The client can request the package `testfile` from the repository. TUF will
|
|
|
|
|
download and verify metadata from the repository as necessary to determine
|
|
|
|
|
what the trustworthy hashes and length of `testfile` are, then download
|
|
|
|
|
the target `testfile` from the repository and keep it only if it matches that
|
|
|
|
|
trustworthy metadata.
|
|
|
|
|
|
2018-01-25 22:33:14 +00:00
|
|
|
```Bash
|
2019-04-04 21:14:13 +00:00
|
|
|
$ cd "../tufclient/"
|
2018-04-06 21:24:15 +00:00
|
|
|
$ client.py --repo http://localhost:8001 testfile
|
2018-06-26 21:07:33 +00:00
|
|
|
$ tree
|
|
|
|
|
.
|
|
|
|
|
├── tufrepo
|
|
|
|
|
│ └── metadata
|
|
|
|
|
│ ├── current
|
|
|
|
|
│ │ ├── 1.root.json
|
|
|
|
|
│ │ ├── root.json
|
|
|
|
|
│ │ ├── snapshot.json
|
|
|
|
|
│ │ ├── targets.json
|
|
|
|
|
│ │ └── timestamp.json
|
|
|
|
|
│ └── previous
|
|
|
|
|
│ ├── 1.root.json
|
|
|
|
|
│ ├── root.json
|
|
|
|
|
│ ├── snapshot.json
|
|
|
|
|
│ ├── targets.json
|
|
|
|
|
│ └── timestamp.json
|
|
|
|
|
└── tuftargets
|
|
|
|
|
└── testfile
|
|
|
|
|
|
|
|
|
|
5 directories, 11 files
|
2018-01-25 22:33:14 +00:00
|
|
|
```
|
2019-04-04 21:14:13 +00:00
|
|
|
|
|
|
|
|
Now that a trustworthy update target has been obtained, an updater can proceed
|
|
|
|
|
however it normally would to install or use the update.
|
2019-02-17 11:05:19 +00:00
|
|
|
|
2018-06-26 21:21:07 +00:00
|
|
|
----
|
2018-01-26 16:23:59 +00:00
|
|
|
|
2019-04-04 21:14:13 +00:00
|
|
|
### Next Steps
|
|
|
|
|
|
|
|
|
|
TUF provides functionality for both ends of a software update system, the
|
|
|
|
|
**update provider** and the **update client**.
|
|
|
|
|
|
|
|
|
|
`repo.py` made use of `tuf.repository_tool`'s functionality for an update
|
|
|
|
|
provider, helping you produce and sign metadata about your updates.
|
|
|
|
|
|
|
|
|
|
`client.py` made use of `tuf.client.updater`'s client-side functionality,
|
|
|
|
|
performing download and the critical verification steps for metadata and the
|
|
|
|
|
update itself.
|
|
|
|
|
|
2019-04-08 15:50:26 +00:00
|
|
|
You can look at [CLI.md](CLI.md) to toy with the TUF CLI a bit more.
|
|
|
|
|
After that, try out using the underlying modules for a great deal more control.
|
2019-04-08 15:56:45 +00:00
|
|
|
The more detailed [Advanced Tutorial](TUTORIAL.md) shows you how to use the
|
2019-04-08 15:50:26 +00:00
|
|
|
underlying modules, `repository_tool` and `updater`.
|
2019-04-04 21:14:13 +00:00
|
|
|
|
|
|
|
|
Ultimately, a sophisticated update client will use or re-implement those
|
|
|
|
|
underlying modules. The TUF design is intended to play well with any update
|
|
|
|
|
workflow.
|
|
|
|
|
|
|
|
|
|
Please provide feedback or questions for this or other tutorials, or
|
|
|
|
|
TUF in general, by checking out
|
|
|
|
|
[our contact info](https://github.com/theupdateframework/tuf#contact), or
|
|
|
|
|
creating [issues](https://github.com/theupdateframework/tuf/issues) in this
|
|
|
|
|
repository!
|