Secure release-note checks for fork pull requests#20081
Conversation
|
@T-Gro I dug into why this suddenly started failing across the hot reload PRs. GitHub announced safer defaults for This workflow itself had not recently changed. Its last repository change was June 8, but it uses the floating I also verified that I do not think contributors should stop using forks, and I do not think I validated it with |
|
🔍 Tooling Safety Check — Affects-Build-Infra
|
|
The explanation makes sense. Let me verify any security risks (should be fewer, just need to check against common exploits). |
Summary
pull_request_targetworkflowactions/github-script@v9GitHub backported safer
actions/checkoutdefaults to floating supported major tags on July 20, 2026. The currentactions/checkout@v2step now rejects the fork checkout before the release-note logic runs, as seen in https://github.com/dotnet/fsharp/actions/runs/30010753188/job/89217916202?pr=20031.Using
allow-unsafe-pr-checkout: truewould restore the old behavior but would preserve the privileged fork-checkout risk. This change keeps fork contributions working without opting out of that protection.Validation
actionlint .github/workflows/check_release_notes.ymlNO_RELEASE_NOTESand produced the expected opt-out result with exit code 0Expected check state
The
check_release_notesresult on this PR is expected to remain red. Thepull_request_targetevent loads its workflow definition from the base branch, so this PR runs the old workflow frommainand fails before it can see the fix. The PR cannot validate its own replacement through this event. After this change merges, subsequent pull request events will use the fixed workflow.Refresh status (2026-07-24)
abb68322f3, with dotnet/fsharp main1dc395ad34merged.actionlint, live release-note and opt-out replays, and stale-head rejection.check_release_notesresult is expected to stay red becausepull_request_targetloads the old workflow frommain. That exception is explained in the Expected check state section above.