ci: GitHub releng for release automation #14888
Conversation
| my $gitDir = $projectRoot // "/home/eelco/Dev/nix-pristine"; | ||
| chdir($gitDir) or die "Cannot chdir to $gitDir: $!"; | ||
| system("git remote update origin") == 0 or die; | ||
| system("git tag --force --sign $version $nixRev -m 'Tagging release $version'") == 0 or die; |
There was a problem hiding this comment.
Do we check somewhere that the signature they're using is one that we have in the repo?
There was a problem hiding this comment.
Not sure such a guard is needed, but I imagine I can add a check afterwards. The keys in-repo would be primarily useful for distros to vendor. We can also link those on the homepage to a key server like the security team does. Though that would be a separate thing, don't want to block on that for now.
There was a problem hiding this comment.
I mean is there any reason to sign a tag with a key that's not in the repo? If not, I think it's good to have a sanity check because it seems plausible someone might be on a different computer than usual or something and forget.
There was a problem hiding this comment.
Can probably be implemented, but it's a bit low-value at the moment I think?
|
What's the procedure for revoking someone's key? Does it invalidate any releases they've already signed? Can we just revoke it going forward? |
|
If the signing key were leaked you'd just plonk down a revocation certificate. |
This allows for testing with a local minio deployment like: ./upload-release.pl --skip-docker --skip-git --s3-endpoint http://localhost:9000 --s3-host localhost:9000 1821360
Previously it was only Eeclo doing releases that were signed with B541D55301270E0BCF15CA5D8170B4726D7198DE. Other linux distributions have the expectation (rightfully so) that our tags are signed. Let's document this. We could do cross-signing to make tracing the chain of trust easier for all Nix team members [1]. [1]: https://nixos.org/community/teams/nix/
This workflow is supposed to automate release uploads by using OIDC for AWS setup. DockerHub still uses long-lived credentials, but that's not fixable. In a follow-up we could set up release uploads to GHCR too.
xokdvium
force-pushed
the
release-github-actions-workflow
branch
from
76242f8 to
84ff2ef
Compare
Usually keys are used to verify new releases. Once a distribution has verified a release they have the correct checksum already in their packaging, which is even better than public key anyway. It's usually not a good idea to rely on public keys for packaging software because there is key rotation/deprecation which would break revisions of your packaging source. |
|
Are we ready to merge? |
|
@Ericson2314, probably good enough. We can test it out for a point release of 2.32 / 2.33. |
xokdvium
added
backport 2.29-maintenance
|
Merging accordingly. |
|
Successfully created backport PR for |
|
Successfully created backport PR for |
|
Successfully created backport PR for |
|
Successfully created backport PR for |
|
Successfully created backport PR for |
5 participants
Motivation
With this change all nix team members will be able to trigger releases.
Docker image uploads tested in my own fork here: https://github.com/xokdvium/nix/actions/runs/20562970644/job/59056274701. At the moment eval id and tag can be mismatched, but that's a pre-existing problem.
Addresses #11469, also fixes the underling issue behind #14315 (we tag master builds in GHCR as
latest).@edolstra, I've also included the public key that's on SKS and you signed all the previous releases with.
Context
Add 👍 to pull requests you find important.
The Nix maintainer team uses a GitHub project board to schedule and track reviews.