fix(ci): replace GITHUB_TOKEN by fine-grained one

[cjdcordeiro]

• Have you signed the CLA?

---

After the recent changes to the GITHUB_TOKEN, the build.yml workflow can no longer push the release artifacts to the GitHub release: https://github.com/canonical/chisel/actions/runs/24026969346

This PR replaces the GITHUB_TOKEN with a new one, managed by us. This new token has contents: write permissions (similarly to the GITHUB_TOKEN), which are unfortunately broad, because GitHub does not offer fine-grained control for releases. The use of the secret is bound to a single step, which runs our own CI script, and always in the context of the base repo and on release events.

[upils]

Thanks @cjdcordeiro. I was a bit worried because this workflow is executed in PRs, but this step is only executed for releases and the secret is only loaded for this specific step so I understand this is fine.

I see that we now have a growing collection of fine-grained tokens and it makes me wonder how much of a burden that will be to maintain. Maybe we should revisit at some point and use the permissions keyword at steps/jobs level to give a bit more permissions to the GITHUB_TOKEN when needed.

[polarathene]

Thanks @cjdcordeiro. I was a bit worried because this workflow is executed in PRs, but this step is only executed for releases and the secret is only loaded for this specific step so I understand this is fine.

pull_request triggered workflows do not have access to secrets. No need to worry about that when GH understands it's a secret :)

pull_request_target however would be a trigger that has risk, as that runs a workflow within a trusted context, allowing access to secrets (however the PR author cannot manipulate that configuration to apply the changes to their PR, which they can for pull_request IIRC).

[niemeyer]

After the recent reports, Paul is right that this does feel suspect since it's basically having a secret on a workflow that looks like it's visible. Can we please at least have a comment in there outlining why this safe, so we keep these concerns in people's minds?

[cjdcordeiro]

After the recent reports, Paul is right that this does feel suspect since it's basically having a secret on a workflow that looks like it's visible. Can we please at least have a comment in there outlining why this safe, so we keep these concerns in people's minds?

@niemeyer sure. Done in 0dd9027.

It's a bit lengthy, but given that it's security-related, I feel like the level of detail is justified.

[niemeyer]

Thanks for the very detailed explanation.

[ROCKsBot]

Command	Mean [s]	Min [s]	Max [s]	Relative
BASE	14.002 ± 0.156	13.740	14.338	1.00 ± 0.02
HEAD	13.997 ± 0.215	13.757	14.269	1.00