Repository navigation
Automated release builds #1550
Description
Description of issue or feature request:
Automate releases to reduce potential for human error and protect against developer machine compromise.
Current behavior:
Current release process is very manual and runs on the local machine of a developer making the release: https://github.com/theupdateframework/tuf/blob/7731738590f291041c06b3c525e248d245cb1f33/docs/RELEASE.md
Expected behavior:
Release process is automated as much as possible and, ideally, happens in a hermetic environment on a hosted build service.
At a minimum we should script releases, but even better would be to define a plan to meet SLSA 2 or above https://slsa.dev/levels
Activity
jku commentedon Sep 1, 2021
The first step seems to be research:
joshuagl commentedon Sep 1, 2021
A big part of this is indeed figuring out, not only the state of the art but also where they violate best practices (standard practice != best practice). Developer signing is the big wrinkle we've run into when thinking about automating this in the past.
For hosted build service, we almost certainly will continue to use GitHub Actions. This might be a starting point: https://github.com/slsa-framework/github-actions-demo
Agreed that a scripted build/release process (
make release?) is the correct starting point.jku commentedon Sep 2, 2021
https://packaging.python.org/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/ I'm not saying we should do this (because of the signing issue) but nice to see that python.org is willing/trying to define "the right way to do this"...
joshuagl commentedon Sep 3, 2021
In future a PyPI build farm, developer signing of PyPI with thresholds (PEP 480), or sigstore trust delegations might make this easier, in the near term some options:
joshuagl commentedon Sep 6, 2021
Having discussed with one of the SLSA creators, I think the SLSA way to achieve automated builds and have developer signing of releases is.
In future, we could either
OR
I think a shared secret managed by a service is the way to go, but we might want to wait for sigstore trust delegations for that?
joshuagl commentedon Oct 8, 2021
For moving the signing to an automated system, it might be as simple as having a new project signing key with the public key stored as a file in the git repo (where our users can easily find it) and the private key is stored in a GitHub secret.
There's even WIP support in sigstore/cosign to generate a key and set up the secrets in GitHub here sigstore/cosign#848
I think we don't want to have individual developers and their PGP keys sign releases, I like binding everything to the GitHub organisation. But if we do want that, we could have automated signed releases by the project which are also approved/signed by the developer who triggered (tagged) the release.
jku commentedon Jan 10, 2022
This is is an issue with normal Github repository secrets as anyone with the ability to create branches in the project practically has the ability to leak the secrets.
Defining a deployment environment might be a way to solve that but I've not looked into those.
jku commentedon Jan 10, 2022
so in practice (let's assume we have ways to verify that build artifacts match):
git tag --sign)The advantage here is mostly auditability: A malicious maintainer can still create a release with something malicious in it, but now github content should reflect that.
is this correct?
joshuagl commentedon Jan 11, 2022
checking we mean
git tag --sign?is the release made (listed on https://github.com/theupdateframework/python-tuf/releases) at this point, or gated on the below verification, along with the PyPI upload?
This verification prevents tampered changes from being uploaded to PyPI.
This verification detects tampering by PyPI. If we sign our PyPI uploads, the verification can be a signature check.
that's right, we want provable linkage between the source in the repo and the artefact being installed. Ultimately we want to prevent tampering, and having documented and verifiable linkage between source and artefacts is necessary to develop a tamper proof process.
jku commentedon Jan 11, 2022
Yes that is what I meant (will edit comment).
Hmm, have not considered this yet. I suppose combining github release and pypi upload makes sense, so both gated behind maintainer approval.
The approval btw is something I believe a github actions deploy job can do: we define a "deploy environment" that can have a list of reviewers who are authorized to approve deployments as well as related environment secrets like pypi credentials)
joshuagl commentedon Jan 11, 2022
That's very neat!
jku commentedon Jan 11, 2022
On second read: this not completely correct I think as tampered changes could still be uploaded to pypi if the infrastructure is tampered cleverly enough... but I think the first check still probably makes sense: a bit of assurance that we are not trying to upload something non-reproducible to PyPI
joshuagl commentedon Jan 11, 2022
True, I could have couched my language a little more or made my implicit threat model (GitHub itself isn't compromised) more explicit.
jku commentedon Jan 31, 2022
On more thing to remember: our
-devrequirements are currently unversioned. That should not be the case if we're trying to control the environment.See #1813