Building Qubes

Published on November 21st, 2017

I'm working with the Freedom of the Press Foundation these days, migrating the journalist interface of SecureDrop away from a processes involving mutiple laptops running tails to a single machine running Qubes. It's been exciting work, especially since Qubes is in the middle of releasing a new major version, which we've decided we want to target.

In its prerelease state, Qubes 4 has been a little shaky. We've been exercising some of its new features pretty hard and have stumbled over some bugs in the process (all of which the Qubes folks have been very responsive in addressing). I'd love to understand some of the Qubes internals a bit better so I can submit PRs instead of just bug reports. Marek gave me some pointers about how to get started, and I'm going to try to document my (sure-to-be-stumbling) process and discoveries here.

I'm working on a machine that's up-to-date with the Qubes 4.0 testing repos as of today (November 21, 2017).

Build a devel VM

I'll be building qubes-builder in a new, standalone qubes-devel VM based on the Fedora-25 template. Use the GUI or cli to create that VM, and be sure to give it plenty of private disk space (the Qubes docs recommend at least 25GB). In its settings window, add at least a terminal to its list of applications.

Open a terminal and install your favorite editor. Edit /etc/yum.repos.d/qubes-r4.repo to ensure enabled is set under [qubes-vm-r4.0-current-testing]. Bring your VM up to date with all the fresh new code with:

Then configure GPG to set that key as ultimately trusted, so it can be used to verify all the keys it signs. This is described at https://www.qubes-os.org/security/verifying-signatures/, and outlined below. In particular, verify that the fingerprint you see matches the one displayed below (and confirm against the fingerprints shown in the link above).

Finally, verify the integrity of the downloaded repository. The last line should read gpg: Good signature from...

$ cd ~/projects/qubes-builder
$ git tag -v `git describe`

Configure the builder

In the root of the project, run setup.

$ cd ~/projects/qubes-builder
$ ./setup

This will start a nice console progam. On the first screen ("Choose Which Qubes Release..."), choose "Qubes Release 4.0". On the next screen, choose "Stable". On the third screen, choose "No" (in order to do a complete build).

On the "Builder Plugins Selection" page, choose the default builder-fedora and mgmt-salt selections. On the "Distribution" page, unselect options until only the fc25 option is selected.

Fetch the source for everything

When the setup script is done, do make install-deps. This'll be pretty quick.

Now:

$ make get-sources

This'll take a while.

Hack

The source code for the entire universe has been checked out in qubes-builder/qubes-src. Go there and make all the bugfixes and magical features you can.

Building

The Makefile in the root of a project is ... comprehensive. It's able to build everything from a single project to a full iso- try make help for the full rundown. In my current case, I'm going to be working in a single component (core-agent-linux), so I was hopeful that simply running make core-agent-linux would work, but sadly it fails.

It turns out that (unsurprisingly) components depend on each other and there's an order in which they should be built. Reading this configuration file shows us that order. So, makeing each component in turn until you've made the one you're working on seems like a fine way to proceed. Of course, subsequent builds of the component you're working on won't require rebuilding dependencies.

So, in my case, I run make for each of these components in turn: vmm-xen, core-libvert, core-vchan-xen, core-qubesdb, linux-utils, core-admin, core-admin-client, core-admin-linux, and finally core-agent-linux.

Once the core-admin-linux component is built, new rpms are left in qubes-src/core-agent-linux/pkgs/fc25/x86_64/. In my case I'll copy those to a new template VM where I'm testing my new agent code.