chore(superagent): disable contributor-trust scoring, keep the security scan - #9818
Merged
Merged
Conversation
…ty scan The contributor-trust check has been posting `action_required` on established contributors' PRs — shin-core scored 10/100 "dangerous" on PR #9816 — and was a major source of manual-review volume. Two independent reasons to turn it off rather than tune it further: 1. The trustedAuthors exemption does not work. shin-core is listed in it and was still flagged. An exemption that does not exempt is worse than none: it looks handled while every affected PR still stalls. 2. Its verdict has no consumer. LoopOver now lists this check under gate.ignoredCheckRuns (#9813) on all three gate repos, so a non-passing result no longer gates, pends, or holds anything. Leaving it on produces a permanently red check on contributor PRs that nothing acts on — noise that makes good contributors think they have failed something. prScan stays enabled and still gates CI normally: that is the protection worth having, and it is a different check from the same app. trustedAuthors is kept (inert) so the history survives if this is ever revisited.
Contributor
|
Important 🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨 ⏳ LoopOver is waiting…LoopOver has seen this pull request and is waiting on CI checks to finish before reviewing it. This comment will update once the review runs. 🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed · 🟨 Waiting |
Contributor
|
Superagent didn't find any vulnerabilities or security issues in this PR. |
It provably does not work (a listed author was still flagged action_required) and is inert with contributorTrust disabled. Keeping it would only suggest the repo has a working exemption mechanism that it does not.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The
Contributor trustcheck (appsuperagent-security) postsaction_requiredon established contributors' PRs. On #9816 it scored shin-core 10/100 · "dangerous" — a contributor with dozens of merged PRs.Two independent reasons to disable rather than tune:
1. The
trustedAuthorsexemption does not work.shin-coreis already listed in it and was flagged anyway. That exemption was added specifically to stop this, so the lever we were relying on is broken — an exemption that doesn't exempt is worse than none, because it looks handled while every affected PR still stalls.2. Its verdict now has no consumer. LoopOver lists this check under
gate.ignoredCheckRuns(#9813) on all three gate repos, so a non-passing result no longer gates, pends, or holds anything. Leaving it enabled only produces a permanently red check on contributor PRs that nothing acts on — noise that makes good contributors think they've failed something.What stays
prScan(the Superagent Security Scan) stays enabled and still gates CI normally — verified passing on #9816's head. It's a different check from the same app, and it's the protection actually worth having.trustedAuthorsis kept but inert, so the history survives if this is ever revisited.Layering
This disables it at the source;
ignoredCheckRunsremains as defence-in-depth in case the app still posts a neutral/skipped run once disabled. If Superagent ignoresenabled: falseentirely, that's a vendor-side issue — but LoopOver will no longer act on the result either way..github/superagent.ymlis not under anyhardGuardrailGlobsentry, so this merges through the normal path.