ci: declare workflow-level `contents: read` on 4 workflows by arpitjain099 · Pull Request #712 · linuxfoundation/lfx-self-serve

arpitjain099 · 2026-05-15T06:57:42Z

Pins the default GITHUB_TOKEN to contents: read on 4 workflows in .github/workflows/ that don't call a GitHub API beyond the initial checkout.

Why

CVE-2025-30066 (March 2025 tj-actions/changed-files supply-chain compromise) exfiltrated GITHUB_TOKEN from workflow logs. Pinning per workflow caps runtime authority irrespective of the repo or org default, gives drift protection if the default ever widens, and is credited per-file by the OpenSSF Scorecard Token-Permissions check.

YAML validated locally with yaml.safe_load on each touched file.

coderabbitai · 2026-05-15T06:57:55Z

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 809ec86a-abe7-4a25-ac46-8cdb77de23fc

📥 Commits

Reviewing files that changed from the base of the PR and between c265ed7 and 5444b07.

📒 Files selected for processing (4)

.github/workflows/license-header-check.yml
.github/workflows/markdown-lint.yml
.github/workflows/pr-title-lint.yml
.github/workflows/quality-check.yml

✅ Files skipped from review due to trivial changes (3)

.github/workflows/license-header-check.yml
.github/workflows/markdown-lint.yml
.github/workflows/pr-title-lint.yml

🚧 Files skipped from review as they are similar to previous changes (1)

.github/workflows/quality-check.yml

Walkthrough

Four GitHub Actions workflows are updated to add explicit permissions: { contents: read } at the workflow level, restricting the GitHub Actions token to read-only access for repository contents in each job.

Changes

GitHub Actions Permission Hardening

Layer / File(s)	Summary
Permission hardening across workflows `.github/workflows/license-header-check.yml`, `.github/workflows/markdown-lint.yml`, `.github/workflows/pr-title-lint.yml`, `.github/workflows/quality-check.yml`	Each workflow adds a top-level `permissions` block setting `contents: read`, constraining the GitHub token to read-only access to repository contents.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'ci: declare workflow-level `contents: read` on 4 workflows' directly and clearly summarizes the main change: adding explicit workflow-level permissions to four workflows.
Description check	✅ Passed	The description provides context about the changes, explains the security motivation (CVE-2025-30066), and describes the validation performed, all directly related to the changeset.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create PR with unit tests

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

dealako

Hi Arpit — thanks for the focused supply-chain hardening. The CVE citation and Scorecard rationale make this easy to follow, and after this PR every workflow in .github/workflows/ carries an explicit permissions cap — a clean Scorecard win.

I verified both upstream reusable workflows (lfx-public-workflows/license-header-check.yml and lfx-ui/_pr-title-lint.yml) to check the actual API surface. Three of the four are clean: license-header-check, markdown-lint, and quality-check need nothing beyond contents: read. The fourth (pr-title-lint) is where the description is slightly off — see the inline comment above.

One process note: the commit shows as unsigned in GitHub's verification (reason: "unsigned"). Repo policy requires both --signoff (present ✅) and GPG signing (-S). A quick git commit --amend --no-edit -S && git push --force-with-lease before merge would bring it in line.

Summary:

Blocking: 0
Minor: 1 (pr-title-lint description accuracy / optional UX fix)
Nits: 2 (missing EOF newline, unsigned commit)

Decision: Fix the code signing - this is a requirement. Otherwise, minor comments — happy to approve once issue 1 is acknowledged either way (description update or add pull-requests: write on that one file).

dealako · 2026-05-15T15:58:25Z

    # Possible values: https://help.github.com/en/actions/reference/events-that-trigger-workflows#pull-request-event-pull_request
    types: [opened, edited, reopened, synchronize]

+permissions:


[minor] The PR description says this workflow "doesn't call a GitHub API beyond the initial checkout," but the upstream reusable workflow (linuxfoundation/lfx-ui/.github/workflows/_pr-title-lint.yml@main) runs morrisoncole/pr-lint-action@v1.7.1 with:

on-failed-regex-comment — posts a PR comment on failure → needs pull-requests: write

on-succeeded-regex-dismiss-review-comment — dismisses a review on success → needs pull-requests: write

With the caller restricted to contents: read, those two API calls will return 403. The lint check itself remains gating (on-failed-regex-fail-action: true still fails the action), but contributors with a bad PR title will see a red ❌ with no explanatory comment, and the success-side review dismissal becomes a no-op.

Two options:

Keep contents: read and update the PR description to note this trade-off (and optionally raise a follow-up in the upstream workflow).

Add pull-requests: write on this file — that still caps the token and satisfies OpenSSF Scorecard, while preserving the comment UX.

dealako · 2026-05-15T15:58:25Z

+
 jobs:
  pr-title-lint:
    uses: linuxfoundation/lfx-ui/.github/workflows/_pr-title-lint.yml@main


[nit] Missing trailing newline (\ No newline at end of file in the diff). Pre-existing condition, but easy to fix in the same commit since you're already touching this file.

dealako

Fix code signing.

arpitjain099 · 2026-05-16T06:47:34Z

Fix code signing.

Hi @dealako thanks for the comment. I will fix this after I get back home tonight.

Pins the default GITHUB_TOKEN to contents: read on the workflows in .github/workflows/ that don't call a GitHub API beyond the initial checkout. The other workflows in this directory are left implicit because they need write scopes that a maintainer is better placed to declare. Motivation: CVE-2025-30066 (March 2025 tj-actions/changed-files compromise) exfiltrated GITHUB_TOKEN from workflow logs. Per-workflow caps bound runtime authority irrespective of repo or org default, give drift protection if the default ever widens, and are credited per-file by the OpenSSF Scorecard Token-Permissions check. YAML validated locally with yaml.safe_load. Signed-off-by: Arpit Jain <arpitjain099@gmail.com>

arpitjain099 · 2026-05-18T00:53:11Z

@dealako pushed a force-with-lease with the commit SSH-signed (now showing as Verified on GitHub). Rebased onto current main while I was at it. Let me know if you'd like me to handle the pr-title-lint description tweak or the missing EOF newline as a follow-up, or leave that for after merge.

dealako · 2026-05-18T15:27:27Z

@arpitjain099 - the one change will break the current behavior. For this one entry, I think the correct solution is to assign write permissions per this discussion.

arpitjain099 · 2026-05-18T15:40:37Z

@arpitjain099 - the one change will break the current behavior. For this one entry, I think the correct solution is to assign write permissions per this discussion.

@dealako noted. let me review this tomorrow.

arpitjain099 requested a review from a team as a code owner May 15, 2026 06:57

dealako reviewed May 15, 2026

View reviewed changes

dealako requested changes May 15, 2026

View reviewed changes

arpitjain099 force-pushed the chore/declare-workflow-perms-readonly branch from 90fe0ba to 5444b07 Compare May 18, 2026 00:52

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ci: declare workflow-level `contents: read` on 4 workflows#712

ci: declare workflow-level `contents: read` on 4 workflows#712
arpitjain099 wants to merge 1 commit into
linuxfoundation:mainfrom
arpitjain099:chore/declare-workflow-perms-readonly

arpitjain099 commented May 15, 2026

Uh oh!

coderabbitai Bot commented May 15, 2026 •

edited

Loading

Uh oh!

dealako left a comment •

edited

Loading

Uh oh!

dealako May 15, 2026

Uh oh!

dealako May 15, 2026

Uh oh!

dealako left a comment

Uh oh!

arpitjain099 commented May 16, 2026

Uh oh!

arpitjain099 commented May 18, 2026

Uh oh!

dealako commented May 18, 2026

Uh oh!

arpitjain099 commented May 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

arpitjain099 commented May 15, 2026

Why

Uh oh!

coderabbitai Bot commented May 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Walkthrough

Changes

Estimated code review effort

Uh oh!

dealako left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dealako May 15, 2026

Choose a reason for hiding this comment

Uh oh!

dealako May 15, 2026

Choose a reason for hiding this comment

Uh oh!

dealako left a comment

Choose a reason for hiding this comment

Uh oh!

arpitjain099 commented May 16, 2026

Uh oh!

arpitjain099 commented May 18, 2026

Uh oh!

dealako commented May 18, 2026

Uh oh!

arpitjain099 commented May 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

coderabbitai Bot commented May 15, 2026 •

edited

Loading

dealako left a comment •

edited

Loading