Tighten secret scope in release.yml
#14627
Conversation
* Add `environment: release` to the "publish-to-hex" job so that only
workflows explicitly targeting the release environment can read
sensitive values.
* Gate the job behind `if: ${{ vars.HEX_AWS_REGION }}` to avoid noisy
failures in forks where the variable is not configured.
* Replace `${{ secrets.HEX_AWS_REGION }}` / `${{ secrets.HEX_AWS_S3_BUCKET }}`
references with `${{ vars.* }}`. These are not credentials, so
environment-level *variables* are a better fit and keep them readable
only by jobs that declare the environment.
* Remove Fastly secrets from the job-wide `env:` block and inject them
only into the Fastly purge step, following the principle of least
privilege. Other steps no longer see these tokens.
Restricting secret visibility to an environment and to the exact step
that needs them reduces the blast radius of a compromised workflow run,
blocks accidental exposure in logs of unrelated steps, and stops forks
from obtaining privileged data.
|
I have added the environment variables and secrets. Is it ready to merge? |
|
@ericmj Yes, if the TODOs were done, this is ready. Please make sure to either backport the change to all still maintained versions or leave the old variables until they are no longer needed. |
* Add `environment: release` to the "publish-to-hex" job so that only
workflows explicitly targeting the release environment can read
sensitive values.
* Gate the job behind `if: ${{ vars.HEX_AWS_REGION }}` to avoid noisy
failures in forks where the variable is not configured.
* Replace `${{ secrets.HEX_AWS_REGION }}` / `${{ secrets.HEX_AWS_S3_BUCKET }}`
references with `${{ vars.* }}`. These are not credentials, so
environment-level *variables* are a better fit and keep them readable
only by jobs that declare the environment.
* Remove Fastly secrets from the job-wide `env:` block and inject them
only into the Fastly purge step, following the principle of least
privilege. Other steps no longer see these tokens.
Restricting secret visibility to an environment and to the exact step
that needs them reduces the blast radius of a compromised workflow run,
blocks accidental exposure in logs of unrelated steps, and stops forks
from obtaining privileged data.
* Add `environment: release` to the "publish-to-hex" job so that only
workflows explicitly targeting the release environment can read
sensitive values.
* Gate the job behind `if: ${{ vars.HEX_AWS_REGION }}` to avoid noisy
failures in forks where the variable is not configured.
* Replace `${{ secrets.HEX_AWS_REGION }}` / `${{ secrets.HEX_AWS_S3_BUCKET }}`
references with `${{ vars.* }}`. These are not credentials, so
environment-level *variables* are a better fit and keep them readable
only by jobs that declare the environment.
* Remove Fastly secrets from the job-wide `env:` block and inject them
only into the Fastly purge step, following the principle of least
privilege. Other steps no longer see these tokens.
Restricting secret visibility to an environment and to the exact step
that needs them reduces the blast radius of a compromised workflow run,
blocks accidental exposure in logs of unrelated steps, and stops forks
from obtaining privileged data.
|
I backported to v1.18 and v1.19. I also removed the repository secrets, if we need them back to ship new versions of <v1.18 hex maintainers can revert this commit: https://github.com/hexpm/hexpm-ops/commit/8188ddeeccd26b391070f7cf479fad50add115bb. |
|
@ericmj https://github.com/elixir-lang/elixir/actions/runs/17445029605/job/49537507599 fails. That is because #14604 is not backported to 1.18. |
|
Okay, backporting that PR to v1.18 also. |
|
@ericmj Hm, there's another issue. I'll open a PR with a fix for 1.18 |
Backported PRs: * elixir-lang#14604 * elixir-lang#14627 The commits are based on the SBoM PR (elixir-lang#14241) which changed the actions.
|
It looks like the upload-builds-hex-pm is being skipped now: https://github.com/elixir-lang/elixir/actions/runs/17493062408/job/49687676489. We have this conditional https://github.com/elixir-lang/elixir/blob/main/.github/workflows/release.yml#L308 but it should be true: 
|
|
@ericmj What is currently listed in |
"No restriction" |
|
Ok, that's not the reason then. I'll debug in my fork and open a PR. You might want to change the "no restriction", that defeats the purpose a bit. In my fork I listed |
|
@maennchen don't we also need it in main, since we are always pushing main builds to Hex as well? |
|
@josevalim Yes, I listed main, v prefixed tags and v prefixed branches. |
|
@ericmj Interesting, |
3 participants
What changed
environment: releaseto thepublish-to-hexjob so that only workflows explicitly targeting the release environment can read sensitive values.if: ${{ vars.HEX_AWS_REGION }}– to skip the job in forks that don’t define release variables.${{ vars.HEX_AWS_REGION }}${{ vars.HEX_AWS_S3_BUCKET }}These are configuration values, not credentials, so variables are a better fit and remain visible only to jobs using the
releaseenvironment.Why it matters
Placing secrets in an environment and scoping them to the minimum surface area:
TODO for Maintainers
HEX_AWS_REGION,HEX_AWS_S3_BUCKETHEX_AWS_ACCESS_KEY_IDHEX_AWS_SECRET_ACCESS_KEYHEX_FASTLY_REPO_SERVICE_IDHEX_FASTLY_BUILDS_SERVICE_IDHEX_FASTLY_KEYOnce the moves are complete, new release builds will run with the tighter permissions automatically.