fix: pr assign workflow perm

[swickersh]

The workflow also needs pull-request write permission

Assisted-by: Cursor AI

[qodo-for-redhat-appstudio]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0)

Context used

✅ Compliance rules (platform): 5 rules

1. Excess PR write permission 🐞 Bug ⛨ Security

Description

The pr-assigner workflow now grants pull-requests: write even though it only calls
pulls.listFiles (read-only) and assigns via issues.addAssignees. Because this runs on
pull_request_target, the unnecessary write scope expands what GITHUB_TOKEN can mutate on PRs,
increasing blast radius if the workflow/action is ever compromised.

Code

.github/workflows/pr-assigner.yaml[R8-11]

permissions:
  contents: read
-  pull-requests: read
-  issues: write # assignees are managed via the Issues API, even on PRs
+  pull-requests: write # required to list PR files and to assign on PRs via the Issues API
+  issues: write

Relevance

⭐⭐⭐ High

PR #445 explicitly reduced pr-assigner perms from pull-requests:write to read + issues:write
(least-privilege).

PR-#445
PR-#36

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The workflow is triggered by pull_request_target and grants pull-requests: write. However, the
only PR-scoped API usage is github.rest.pulls.listFiles (read-only), while the only mutation is
github.rest.issues.addAssignees, which is covered by issues: write without needing PR write
permission.

.github/workflows/pr-assigner.yaml[4-11]
.github/workflows/pr-assigner.yaml[39-47]
.github/workflows/pr-assigner.yaml[132-138]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The workflow grants `pull-requests: write`, but the current script only needs to read PR files (`pulls.listFiles`) and write assignees via the Issues API (`issues.addAssignees`). This over-scopes `GITHUB_TOKEN` for a `pull_request_target` workflow.

## Issue Context
`pull_request_target` workflows run with base-repo context and the declared `GITHUB_TOKEN` permissions. Least-privilege is important because any unnecessary write scope increases impact if a step/action is compromised.

## Fix
- Change `permissions.pull-requests` back to `read`.
- Update the inline comment to accurately reflect why `pull-requests` permission is needed (listing files).
- Keep `issues: write` for `issues.addAssignees`.
- If you have an observed 403 requiring PR write in practice, document the exact failing API call and keep the narrowest permission that unblocks it.

## Fix Focus Areas
- .github/workflows/pr-assigner.yaml[8-11]
- .github/workflows/pr-assigner.yaml[39-46]
- .github/workflows/pr-assigner.yaml[132-138]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[qodo-for-redhat-appstudio]

PR Summary by Qodo

Fix pr-assigner workflow by granting pull-requests write permission
🐞 Bug fix ⚙️ Configuration changes 🕐 Less than 5 minutes

Walkthroughs

Description

• Grant the pr-assigner workflow pull-requests: write to enable PR file listing and assignments.
• Keep the workflow using the Issues API while ensuring required least-privilege access.

Diagram

graph TD
  A["pr-assigner workflow"] --> B["GITHUB_TOKEN permissions"] --> C["GitHub API"] --> D["Pull request"]
  C --> E["Issues API (assignees)"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Set permissions at the job level only

• ➕ Further reduces scope of elevated permissions if multiple jobs exist later
• ➕ Aligns with least-privilege practices for Actions
• ➖ No practical benefit if there is only one job
• ➖ Slightly more verbose YAML

2. Use `permissions: write-all`

• ➕ Avoids future permission-related failures if the workflow expands
• ➖ Overly permissive; increases security risk and deviates from least privilege

Recommendation: The current approach (explicitly granting pull-requests: write alongside issues: write) is the right fix and maintains least privilege. Only consider job-level scoping if the workflow grows additional jobs with different permission needs.

File Changes

Other (1)

pr-assigner.yaml Elevate PR permissions to enable assignment workflow operations +2/-2

Elevate PR permissions to enable assignment workflow operations

• Updates workflow permissions to 'pull-requests: write' so the workflow can list PR files and perform PR-related assignment operations (via the Issues API). Keeps 'contents: read' and retains 'issues: write' for assignee management.

.github/workflows/pr-assigner.yaml

---

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: enkeefe00, swickersh

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [enkeefe00]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment