How are release artifacts attached?

[jaredledvina]

Howdy!

I'm curious what the release process is for attaching the artifacts to each release (i.e. on https://github.com/opencontainers/runc/releases/tag/v1.3.1). I'm not seeing a Github action that would setup the release and attach the artifacts. Is a maintainer taking the artifacts from the validate job (i.e. https://github.com/opencontainers/runc/actions/runs/17817435157) downloading them, signing them, and then attaching all of that to the release page?

I'm curious in the process as it doesn't seem to be outlined in the docs as far as I can find and am testing out changes over on a fork. Thanks for your time!

[cyphar]

I run make [email protected] releaseall on my local machine and upload the artefacts.

As Go builds are reproducible (though there are aspects to this we could improve such as including a copy of the container image used for the build) users can independently verify that the binaries genuinely come from the source code.

There are two reasons why I still have a manual process for this:

1. I need to sign the artefacts with my GPG key. We could still do the build elsewhere and sign separately (that is kind of how it works now because the build is done in a container these days) but I prefer having it be one step.
2. The idea of doing releases from GitHub Actions servers gives me the creeps. GHA infrastructure is far too juicy of a target to implicitly trust and there have been far too many examples of subtly broken GHA configurations resulting in disaster. The recent supply chain attacks against NPM have only further validated this view IMHO. If I downloaded the GHA-built binaries and signed them, I also would still need to rebuild then locally to make sure they were not tampered with, so I'm not sure it makes sense to add the extra download step.

[jaredledvina]

Great, thanks so much! Understood the logistics, I was mostly just looking to confirm my understanding. Appreciate it!