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

ci: split PR severity workflow into classify and apply jobs

Public commit record

What the developer wrote

Authored by Olaoluwa Osuntokun

85/100 · Strong
ci: split PR severity workflow into classify and apply jobs

In this commit, we separate the two concerns in the PR severity workflow:
working out the severity, and applying it. The classify job inspects the
PR and records its verdict (the severity level, whether to comment, and
the comment body) to a few files. A second apply job reads those files
and does the mechanical work of setting the label and posting the comment.

Pulling the classification apart from the application keeps each job doing
one thing and makes the flow easier to follow. The apply job takes the
severity the classifier picked and checks it against the known set before
touching a label, and posts the comment from a file via --body-file so the
body is handled as plain data. We also turn off checkout credential
persistence, since neither job needs a git credential on disk.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit is a hardening and cleanup of a GitHub Actions workflow that automatically labels pull requests by severity. It does not change any LND node code, wallet logic, or network protocol. Instead, it splits the workflow into two jobs: a read-only 'classify' job that runs an AI model to decide the severity, and a separate 'apply' job that actually sets the label and posts the comment. The change reduces security risk by keeping write permissions out of the job that processes untrusted pull-request text, pins the external AI action to a fixed commit hash, disables unnecessary git credentials, and adds input sanitization for the model-generated comment. It is a defensive improvement, not a vulnerability fix.

Recommended action

No urgent action is required; this is a defensive CI hardening change. Reviewers should verify that the apply job's artifact download cannot be influenced by fork-PR authors (it uses the internal artifact name and the trusted event payload), and that the unit tests are run in CI. Consider extending the sanitizer if new notification/spam vectors are identified.

Security signals we found

01

Principle of least privilege: write token moved out of the model-bearing job

02

Untrusted input (model-generated comment) sanitized before privileged API use

03

External action pinned to immutable commit SHA instead of mutable tag

04

Workflow default permissions lowered to read-only

05

Git credential persistence disabled

06

Job timeout added to bound resource consumption on attacker-triggered events

07

Single atomic gh pr edit prevents inconsistent multi-label state

08

Severity validated against an explicit allowlist before label mutation

Risk score

Why this scored 15/100

Our methodology →
Potential impact 0/30
Exploitability 0/25
Stealth signal 0/15
Affected reach 0/15
Confidence 10/10
Evidence quality 5/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.