AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Informational 21 Bitcoin

build: read live PR labels in check-label action

Public commit record

What the developer wrote

Authored by ziggie

92/100 · Strong
build: read live PR labels in check-label action

The check-label composite action evaluated
github.event.pull_request.labels, which is a snapshot captured when the
pull_request event fired. A label such as no-changelog or no-itest added
after the run kicked off was therefore never seen, not even when
re-running the failed job, because a re-run reuses the original event
payload. The only workaround was pushing a new commit.

Query the current label set through the API instead and only fall back
to the event payload when there is no PR number (push and merge_group
runs) or the API call fails. Re-running a failed job now picks up labels
added after the run started.

The workflow declares explicit permissions, so grant pull-requests: read
for the API call.
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Explains rationale or failure mode
The short version

What changed, and why it matters

This is a GitHub Actions workflow fix, not a vulnerability in the LND lightning node software itself. It changes how a CI check reads pull-request labels so that re-running a failed job sees labels added after the run started. The change adds a GitHub API call and grants the workflow read-only access to pull-request metadata. There is no direct security risk to LND users or funds.

Recommended action

No security action required. Reviewers may verify the new `pull-requests: read` permission is scoped only to the intended job and that the API call cannot be abused to leak repository metadata beyond labels.

Security signals we found

01

New GitHub API token usage (GH_TOKEN: ${{ github.token }})

02

New workflow permission added: pull-requests: read

03

CI-only change; no application code modified

Risk score

Why this scored 21/100

Our methodology →
Potential impact 2/30
Exploitability 3/25
Stealth signal 2/15
Affected reach 2/15
Confidence 8/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.