Have CI build nightlies for securedrop-updater

[legoktm]

In theory it's general but currently expecting the pending securedrop-updater Makefile and folder layout and assume that securedrop-workstation's rpm will be modified to follow this layout too.

Fixes https://github.com/freedomofpress/securedrop-updater/issues/10

[legoktm]

Also the infra scripts need to be updated to handle a -nightlies folder.

[legoktm]

Building and pushing "works", I just forgot that we need to sign the rpm before pushing. https://github.com/freedomofpress/securedrop-workstation-dev-rpm-packages-lfs/commit/8489fa4e13bb56a50461dc57aa2c2451780e4062

🤔

[legoktm]

The rpm test signing key (4ED79CC3362D7D12837046024A3BE4A92211B03C) is currently kept private and individual developers have copies of it. rpm packages are individually signed rather than the repository metadata (apt/dpkg), so we need to figure out how CI/automation is expected to sign the packages. Just listing out the options:

1) CircleCI has access to the private key and signs the packages. We currently use CircleCI to build the packages, so we already trust CircleCI at some level to not tamper with them. 1b) CircleCI does not have a recent good security track record, so maybe we use GitHub Actions (or some other host) for buliding and give that access to the private key. 2) Packages in the repository are unsigned, but the automation on yum-test.sd.o signs the rpms before generating repodata. This is similar to the apt-test workflow, where the private key lives on the server and it signs the repo metadata before publishing. 3) ??

An attacker with access to the private key would also need push access to the securedrop-workstation-dev-rpm-packages-lfs repo (or access to the yum-test server) to publish malicious packages, which would be installed into dom0 of developer laptops. If we had nightlies with autosigning, presumably it would be easier to just get malicious code into a github repo, which then gets built and pushed as a nightly.

[eloquence]

Packages in the repository are unsigned, but the automation on yum-test.sd.o signs the rpms before generating repodata. This is similar to the apt-test workflow, where the private key lives on the server and it signs the repo metadata before publishing.

This seems like a reasonable option from my end, as it largely replicates the security model we're already using for another package format. If you, @l3th3 and others agree, I would suggest opening an infra issue to that effect -- perhaps this could be an opportunity for direct collaboration with the infra team on that codebase.

[cfm]

Happy to review this once signing is addressed, @legoktm, unless you'd rather @eaon pick it up. :-)

[ghost]

@eloquence that option seems reasonable to me, I'd be fine moving forward with that

[ghost]

Just had a quick discussion with @legoktm about this. Following up, I don't think there's any issue with keeping the test signing key on the server. As has already been mentioned, it matches the model that we already use elsewhere, and we already rely on the assumption that our CI/CD pipeline isn't compromised.

So long as we make it clear that nightlies do not have the same safety guarantees as release packages, I think we can move forward with this.

[legoktm]

OK, we're all set on the infra side so @cfm this is ready for your review :)

We also need to land https://github.com/freedomofpress/securedrop-yum-test/pull/44 - I think that will require admin access (@eloquence?) to remove the project from CircleCI first.

[eloquence]

Done. The steps were:

1. Instruct CircleCI to stop building the repo via CircleCI project settings (CircleCI inherits org-level admin permissions)
2. Amend the commit to ensure that checks are re-run.