From 49afb68d793c1f880e95eef83b45968127347268 Mon Sep 17 00:00:00 2001 From: Cristovao Cordeiro Date: Mon, 20 Apr 2026 22:01:07 +0200 Subject: [PATCH 1/2] fix(ci): replace GITHUB_TOKEN by fine-grained one (#284) 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. --- .github/workflows/build.yml | 25 ++++++++++++++++++++++++- 1 file changed, 24 insertions(+), 1 deletion(-) diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml index 0750993e..7709e54a 100644 --- a/.github/workflows/build.yml +++ b/.github/workflows/build.yml @@ -114,7 +114,30 @@ jobs: CHISEL_VERSION: ${{ steps.build.outputs.CHISEL_VERSION }} ARCHIVE_FILE: ${{ steps.archive.outputs.ARCHIVE_FILE }} ARCHIVE_FILE_SHA384: ${{ steps.archive.outputs.ARCHIVE_FILE_SHA384 }} - GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} + # If triggered by a "release" event, this additional and final step + # of the job will upload the Chisel binaries (and checksums) to the corresponding + # GitHub release. This operation NEEDS "contents: write" permissions. + # Security concerns: + # - Why a custom token instead of GITHUB_TOKEN? + # - The GITHUB_TOKEN only has "readonly" permissions by default. + # - Why not add "permissions: {contents:write}" to this workflow [1]? + # - While this would elevate the GITHUB_TOKEN permissions to what we require, it + # would do it for the entire job (ALL steps), which increases the attack surface unnecessarily. + # - Why is it safer to use the ROCKSBOT_CHISEL_CONTENTS token? + # 1. it is limited to this step of the workflow (unlike GITHUB_TOKEN, which is always available) + # 2. this particular step only runs when the "event == release" + # 3. the step's script doesn't rely on 3rd party actions + # 4. the current workflow triggers are all maintainer-driven, except for "pull_request", + # but the latter is designed not to use any secrets during execution from fork-based PRs + # - NOTE: in fact, custom secrets are never passed to fork-based PR workflows, unlike GITHUB_TOKEN + # which is available with "readonly" permissions [2] + # - How could this token be compromised? + # - By unintentionally merging a change that allows this step to run unvetted scripts + # (either via a "pull_request_target", use of an insecure 3rd party action, or malicious changes to the + # current script) + # [1] https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#permissions + # [2] https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#workflows-in-forked-repositories + GITHUB_TOKEN: ${{ secrets.ROCKSBOT_CHISEL_CONTENTS }} if: ${{ github.event_name == 'release' }} run: | echo "Uploading $ARCHIVE_FILE to release $CHISEL_VERSION" From c3354b9d476354319f5895ffaec93e25f3a3cc7f Mon Sep 17 00:00:00 2001 From: Paul Mars Date: Thu, 23 Apr 2026 13:50:05 +0200 Subject: [PATCH 2/2] ci: trigger ci