Privileged GitHub workflows use mutable third-party refs

[failuresmith]

Summary

Some privileged GitHub workflows use third-party reusable workflows or actions pinned to mutable refs like @v1, @main, and @master.

That means upstream changes can change privileged behavior without any change in this repository.

• /.github/workflows/semantic-pull-request.yml uses pull_request_target and imports ipdxco/unified-github-workflows/...@v1
• /.github/workflows/generated-pr.yml imports ipdxco/unified-github-workflows/...@v1 with issues: write and pull-requests: write
• /.github/workflows/stale.yml imports ipdxco/unified-github-workflows/...@v1 with issues: write and pull-requests: write
• the current upstream reusable generated-PR workflow runs galargh/stale@main
• /.github/workflows/interop-test.yml passes AWS credentials to libp2p/test-plans/.github/actions/...@master

Expected behavior

Workflows with write permissions, pull_request_target, or cloud credentials should run only immutable third-party code pinned to full commit SHAs.

Actual behavior

These workflows currently depend on mutable third-party refs. The effective code path can change after review while keeping the same local workflow files and permissions.

Relevant log output

# .github/workflows/semantic-pull-request.yml
on:
  pull_request_target:
jobs:
  main:
    uses: ipdxco/unified-github-workflows/.github/workflows/reusable-semantic-pull-request.yml@v1



# .github/workflows/generated-pr.yml
permissions:
  issues: write
  pull-requests: write
jobs:
  stale:
    uses: ipdxco/unified-github-workflows/.github/workflows/reusable-generated-pr.yml@v1



# current upstream reusable-generated-pr workflow
- uses: galargh/stale@main



# .github/workflows/interop-test.yml
- name: Run chromium/native tests
  uses: libp2p/test-plans/.github/actions/run-transport-interop-test@master
  with:
    s3-secret-access-key: ${{ secrets.S3_LIBP2P_BUILD_CACHE_AWS_SECRET_ACCESS_KEY }}

Possible Solution

1. Replace mutable refs like @v1, @main, and @master with full commit SHAs.
2. Start with the highest-risk workflows first:
   • semantic-pull-request.yml
   • generated-pr.yml
   • stale.yml
   • interop-test.yml
3. Re-check whether each workflow still needs its current token permissions or AWS credentials.

Version

No response

Would you like to work on fixing this bug?

Yes