feat: auto-rebase all open PRs onto master

[Copilot]

Summary

Adds automated rebase infrastructure so every open PR is kept up-to-date with master without manual intervention.

What's added

.github/workflows/auto-rebase.yml — GitHub Actions workflow that:

• Triggers automatically on every push to master (rebases all open PRs)
• Can be triggered manually via workflow_dispatch (optionally targeting a single PR number)
• For each open PR it:
  1. Skips PRs where the author hasn't enabled "Allow edits from maintainers" (required to push to fork branches)
  2. Detects whether the branch is already up-to-date and skips if so
  3. Runs git rebase -X theirs master — resolves all conflicts automatically by preferring the PR's own changes
  4. Falls back to per-file resolution for lockfiles (pnpm-lock.yaml, package-lock.json, yarn.lock, bun.lockb) when the merge strategy can't auto-resolve them
  5. Regenerates pnpm-lock.yaml (via pnpm install --no-frozen-lockfile) when package.json changed
  6. Pushes the rebased branch back to the fork using gh auth setup-git (token never embedded in URLs)
  7. Comments on the PR with a success or failure message including instructions for manual resolution when needed

scripts/rebase-prs.sh — Companion shell script for local/manual use with the same logic. Accepts optional PR numbers as arguments; defaults to all open PRs.

Security considerations

• User input (pr_number) is passed via environment variable, not interpolated directly into shell code (prevents injection)
• GitHub token is configured via gh auth setup-git rather than embedded in git remote URLs
• force-with-lease is used instead of --force to guard against overwriting concurrent pushes

Important note for fork PRs

Because all 29 outstanding PRs are from external forks, the push step requires each PR author to have enabled "Allow edits from maintainers" in their PR settings. PRs where this is disabled will be skipped with an explanatory comment. Once this workflow is merged to master, trigger it manually (Actions → Auto Rebase PRs → Run workflow) to immediately rebase all eligible PRs.

Checklist

• Workflow YAML is syntactically valid
• Shell script passes shellcheck
• No tokens or secrets in code
• Consistent with existing workflow conventions (test.yml)

[github-actions]

vu1nz Security Review

1 finding(s) in PR #268

MEDIUM: 1

Findings

Severity	File	Issue	Suggestion
MEDIUM	.github/workflows/auto-rebase.yml	Command injection via unsanitized fork repository name in git push URL	Validate and sanitize the FORK_REPO variable before using it in git commands. Add input validation like: `if [[ ! "$FORK_REPO" =~ ^[a-zA-Z0-9._-]+/[

Full AI Analysis

After carefully reviewing this GitHub Actions workflow and shell script for auto-rebasing PRs, I found one security issue:

Severity	File	Line	Issue	Suggestion
Medium	.github/workflows/auto-rebase.yml	171	Command injection via unsanitized fork repository name in git push URL	Validate and sanitize the FORK_REPO variable before using it in git commands. Add input validation like: if [[ ! "$FORK_REPO" =~ ^[a-zA-Z0-9._-]+/[a-zA-Z0-9._-]+$ ]]; then echo "Invalid repo format"; exit 1; fi

Analysis Details

The security issue occurs because the workflow constructs a git push URL using the FORK_REPO variable directly from GitHub API response without validation:

git push "https://github.com/${FORK_REPO}.git" "HEAD:refs/heads/$HEAD_BRANCH" --force-with-lease

While GitHub's API should return properly formatted repository names, an attacker could potentially manipulate this if they control the fork repository name or if there's an API response injection. The risk is somewhat mitigated because:

1. The FORK_REPO comes from GitHub's API, not direct user input
2. GitHub has restrictions on repository naming
3. The git command would likely fail rather than execute malicious code

However, it's still a best practice to validate external data before using it in shell commands.

Other Security Considerations (Not Vulnerabilities)

The workflow follows several good security practices:

• Uses minimal required permissions (contents: write, pull-requests: write)
• Uses GITHUB_TOKEN (not a custom PAT)
• Validates PR conditions before processing
• Uses set -euo pipefail for error handling
• Fetches with limited depth where possible
• Uses --force-with-lease instead of --force for safer pushes

The overall design is reasonably secure for its intended purpose.