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. To do this, follow these steps:

0. Ensure the build-nightlies-once workflow exists in .circleci/config.yml on the please-build-nightlies branch (otherwise this process won't work).
1. Rebase please-build-nightlies from the latest main. If please-build-nightlies is already up-to-date with main, just git --amend HEAD.
2. Now force push this change which will trigger the circleci config to fire off the jobs immediately.

If it's been a while and you don't see your packages on apt-test, you can ask someone who is able to ssh to apt-test.freedom.press to run reprepro-auto-publish --regenerate from the /var/www/reprepro directory as the reprepro user.

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:

Note: For buster builds, clone debian-10 instead

qvm-clone debian-11 t-sd-dev  # Templates default to no NetVM
qvm-volume resize t-sd-dev:root 20G
qvm-create t-sd-dev-dvm --label blue --template t-sd-dev  # This creates an AppVM, which will default to having network access
qvm-prefs t-sd-dev-dvm template_for_dispvms True  # And now we configure our AppVM to be a template for creating our named DispVM
qvm-features t-sd-dev-dvm appmenus-dispvm 1
qvm-create sd-dev-dvm --label blue --template t-sd-dev-dvm --class DispVM  # Create the actual named DispVM

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.

A couple pointers:

• 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
• You can save time by installing the dependencies for securedrop-builder inside t-sd-dev (which doesn't have a network) by installing these dependencies directly: https://github.com/freedomofpress/securedrop-builder/blob/c0167ee9f73feab10bf73d1dd1706309eddf4591/scripts/install-deps#L5-L22.

Which packages are served where?

See the Packging server repos and URLs page.