FAQ

How to trigger SDW nightlies

We use the please-build-nightlies branch to trigger the build and deployment of the latest component code on the main branches of each component's respective repo (see https://github.com/freedomofpress/securedrop-debian-packaging/commit/c7b1d60e7c9158f94125ac79789986f8c904424e). To do this, first we rebase the branch from main, which will modify the circleci config to fire off the jobs immediately.

How to do a diff review

Follow this step-by-step guide: https://github.com/freedomofpress/securedrop/wiki/Dependency-specification-and-update-policies#step-by-step-procedure

Why do we perform diff reviews?

We review the source code of our dependencies for security vulnerabilities that could compromise SecureDrop and SecureDrop Workstation. Specifically, we want to guard against supply chain attacks where an upstream dependency was compromised and begins to ship malicious code.

Counter arguments:

• Given limited review bandwidth, diff reviews only provide partial mitigation, especially e.g. for C code changes.

Are reproducible wheels necessary in order to make the Debian packages that we ship reproducible?

No, even if a wheel is not reproducible, the derivative Debian package would still be reproducible as long as it includes the same verified wheel each time it is built.

Why do we keep local wheels?

Given that some of our dependencies on PyPI are not built reproducibly, we cannot programmatically verify that the binary wheel was built from the exact source tarball that we diff-reviewed. By building from the source tarball ourselves, we can be sure that's the case. Additionally, we can ensure that the build environment used to create the wheel artifact was sufficiently patched.

Counter arguments:

• Some of our dependencies are reproducible so we could verify the hash of the wheel on PyPI (we only need to build the wheel once and keep record of the hash). It would make it clearer which dependencies are actually requiring us to maintain local wheels.
• We know examples of account-level compromises, but we don’t know examples of tainted binary artifacts released alongside pristine source artifacts. Can we find one incident in the wild?

Why do we care about reproducible wheels?

Any wheels we upload to PyPI should be reproducible so that consumers can verify them. We also care about our external dependencies being reproducible so that we can verify that the wheel came from the source tarball that we diff-reviewed. If all our dependencies were reproducible then we wouldn't need to maintain local wheels.

How do I create a local environment suitable for building packages?

To avoid inadvertently contaminating a build environment with development changes, we'll use a DispVM. All SecureDrop Workstation packages require Debian Buster (as of Q12022), so we'll create a VM hierarchy that's based on Debian 10 as TemplateVM (for customizing system packages), then uses an AppVM based on that template (to customize home directory), and finally a DispVM that reuses that AppVM image and deletes customizations on each run. In dom0, run:

qvm-clone debian-10 t-sd-dev
qvm-volume resize t-sd-dev:root 20G
qvm-create t-sd-dev-dvm --label blue --template t-sd-dev --property template_for_dispvms=true
qvm-create sd-dev-dvm --label blue --template t-sd-dev-dvm --disp
qvm-features sd-dev-dvm appmenus-dispvm 1

You may wish to customize the t-sd-dev-dvm home directory to contain personal dotfiles, containing your git config and setting QUBES_GPG_DOMAIN. Also, you can save time by installing the packages from make install-deps inside t-sd-dev. When you want to build a package, open a Terminal in sd-dev-dvm, clone the necessary repo or repos, and remember to save your build logs.

Which packages are served where?

See the Packging server repos and URLs page.