libp2p / libp2p/rust-libp2p

Privileged GitHub workflows use mutable third-party refs

Open
#6,406 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
5.6k
Forks
1.3k
Avg merge
8h 47m
Merged PRs (30d)
19

Description

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

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading .github/workflows/semantic-pull-request.yml, generated-pr.yml, stale.yml, and interop-test.yml, then inspect the referenced upstream workflows and actions. Replace mutable third-party refs with full commit SHAs and re-check the listed write permissions and AWS credentials; done means privileged workflows no longer depend on mutable refs.

Written by the indexing model from the issue text.

Assessment

Tech stack
github-actions
Domain
ci-cd, security
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.