Automate builds using CI

[redshiftzero]

this is dependent on freedomofpress/securedrop-proxy#6, but it keeps coming up and it would automate a lot of pretty boring manual work team members are doing

proposal:

• we build each package every night
  • why every night? so that if a developer makes a change that breaks our builds over in the relevant repo, the issue is discovered quickly and prior to needing to cut a release
  • we allow CI to push packages to a test apt server
  • why not do this as part of CI in the relevant repo? because we're putting all our build logic in this repo
• run make safety checks as part of this nightly CI
  • why? so that if a vulnerability is found in one of our dependencies we are not relying on github's (imho) sometimes unreliable vulnerability alerts
  • while we do have safety checks in all our repos, we also don't want to rely on there being a CI build in that repo

[msheiny]

• So does this proposal signify a change in traditional FPF security requirements regarding physical build servers + air-gapped signing keys?
• will these artifacts only be used for test? in other words, is there possibility of them getting promoted to production?

[conorsch]

At this point we can neatly side-step the security implications for prod by using the CI-built packages only for test. The CI server would need access to the test key for signing, which is acceptable.

For now, let's plan on sticking to building for prod on local (preferably dedicated) hardware. Happy to discuss that plan with eye to changing it, but the packaging story is still rough, so let's iron that out first, so we're not endlessly retooling.

[redshiftzero]

So does this proposal signify a change in traditional FPF security requirements regarding physical build servers + air-gapped signing keys?

i was thinking that the scope of this is just for testing for now

will these artifacts only be used for test? in other words, is there possibility of them getting promoted to production?

just for test given the above security requirements, i think we couldn't promote these artifacts to prod without other changes (e.g. like a totally reproducible build process)

what do you think?

[msheiny]

what do you think?

👍 No time for squabbling in here! I got CI to build ! I'm just asking questions

[conorsch]

We should also include e.g. lintian to catch problems like shipping .pyc files in the deb packages. See discussion in #33 (comment)

[redshiftzero]

These comments are based on some discussions between myself, @emkll, @creviera and @rmol at Pycon.

Core SD:

For SecureDrop core, we generally want to build rc debian packages so we:

0. Add circle CI job that runs on *-rc tags only
1. Builds packages using existing logic
2. Commits directly to test only lfs repo
3. Cron job runs every e.g. hour to run ansible playbook to put up whatever is in the lfs repo at apt-test.freedom.press

Production packages will be built and put up manually as before.

Workstation SD:

For the workstation, we mostly just want to have nightly package builds so we can be always testing the latest master in the qubes workstations to shake out issues.

Nightly package build:

0. First as a pre-requisite, we'll need to run make requirements whenever we do dependency updates in the securedrop-client and securedrop-proxy so that they are always in a state where they are ready to build (meaning we also update our FPF pip mirror at that time).
1. Modify nightly circle CI job in [securedrop-proxy] Log securedrop-proxy exceptions securedrop-proxy#142 to first increment version to e.g. year.month.day, then build as normal
2. Commit artifact to test only lfs repo
3. Cron job runs every night to put up whatever is in that lfs repo on the qubes apt repo

thoughts?

[eloquence]

This was discussed internally today, and the tickets above reflect current consensus on how to proceed. The following tickets are good near-term candidates that are not blocked on infra work:

• Completion of initial build automation in [securedrop-proxy] Log securedrop-proxy exceptions securedrop-proxy#142 (blocked on a client release)
• Policy update for dependency changes (Add policy for requirements updates to facilitate nightly builds #48)
• Implementing version bump logic: Add update_version.sh to automate version bumps for nightly builds securedrop-client#407 and [securedrop-proxy] Add update_version.sh to automate version bumps for nightly builds securedrop-proxy#139
• Using version bump logic in build automation: [securedrop-proxy] Add Buster build job securedrop-proxy#143

[redshiftzero]

closing this since it's been broken down into the existing workstation CI tickets and freedomofpress/securedrop-proxy#63