This tutorial will show you how to:
We recommend a modern Unix-like operating system (eg. Ubuntu or OSX). On Windows OS, we suggest using Virtualbox to get a working Linux system.
We use Git as a version control system, so make sure that it’s installed:
$ sudo apt install git # For Debian
$ brew install git # For OSX
We use DDEV to build and manage a Docker-based local development environment. Installing it should just require:
$ curl -LO https://raw.githubusercontent.com/drud/ddev/master/scripts/install_ddev.sh && bash install_ddev.sh
If that doesn’t work, refer to the DDEV Installation instructions.
Finally, make sure to install a local Certificate Authority (CA):
$ mkcert -install
This allows DDEV to provide locally hosted sites under HTTPS without triggering browser warnings.
We use Drumkit to automate common development tasks. Drumkit requires GNU Make, so make sure that it’s installed:
apt install make # For Debian
brew install make # For OSX
For development and testing, this project uses Git submodules. So make sure to use --recursive whenever you clone the project. If you ever forget to, you can always run git submodule update --init from within the project.
git clone --recursive https://gitlab.com/rugged/rugged.git
cd rugged
First, we need to bootstrap Drumkit:
$ . d # on Bash shells
$ source d # on non-Bash shells
N.B. We’re sourcing the file d here. This loads some variables into the environment for this terminal session. You’ll need to run . d (or source d) whenever you want to use Drumkit in a new terminal.
Next, we can start the DDEV Docker containers:
make start
In order to explore Rugged’s functionality, it’s easiest to start by creating some sample content:
$ make fixtures
You can then review the generated fixtures with:
$ tree fixtures
In particular, the TUF metadata Rugged generates can be found at fixtures/tuf_repo/metadata.
Finally, let’s run a few Rugged commands to see what’s going on.
We’ve added a DDEV command that delegates calls to rugged into the “packaging pipeline” container. For convenience, it also handles calling rugged, via sudo as the ‘rugged’ user.
ddev rugged
We can now see the various sub-commands that are available. Next, let’s see what’s in the logs:
ddev rugged logs
This prints the last 10 lines of the logs of each of the Rugged workers. Many commands support a --worker option, that will show just the results from a single worker.
Let’s try that option out when we look at the status of the repo:
ddev rugged status --worker=targets-worker
This display all relevant information about the state of the repo from the target worker’s perspective.
Let’s try again, but look at the timestamp worker’s status
ddev rugged status --worker=timestamp-worker
One difference worth noting between these is which role has the “Signing” capability. Each worker performs a specific role withing the TUF system. With one important exception (the root worker), each will only have access to a single signing (ie. private) key. This is a key aspect of the TUF security model.
We suggest that you check out the other tutorials and how-to guides next.
Alternatively, you can also read more background information about how and why Rugged operates the way that it does.