tcfeed: 33 requests out, 7 answered, none accepted — fix the workflow, ask first, answer the CodeQL question

[ralyodio]

What happened

The first batch of tcfeed pr requests has now been answered. Six went out; five are closed and none merged.

Repo	Outcome	What the maintainer said
capstone-engine/capstone#3033	closed	"Please open an issue about this first for discussion."
cloudflare/workers-sdk#15168	closed	"At this time we're not intending to integrate with ThreatCrush."
miroslavpejic85/mirotalk#343	closed	"I really appreciate it, but it's not planned for now."
kane50613/takumi#1232	closed	no human comment; CodeRabbit review only
chrisleekr/binance-trading-bot#732	closed	no human comment; CodeRabbit scored it 🟡 Moderate
NeptuneHub/AudioMuse-AI#856	open, checks red	SonarCloud quality gate failed

Elsewhere a maintainer closed one with: "I'll look into security scanning options in the future, likely GitHub's built-in CodeQL/secret scanning first. Appreciate the transparency on the disclosure."

Three separate signals are worth separating, because only one of them is about the pitch.

1. The workflow we ship fails security review

This is the one to fix first, and it is not a matter of persuasion.

SonarCloud's gate on AudioMuse-AI#856 fails our own file with a C security rating on new code. Two MAJOR vulnerabilities, both on the install line:

githubactions:S6505  Omitting "--ignore-scripts" allows lifecycle scripts to run
                     during package installation.
githubactions:S8543  Using dependencies without locking resolved versions is
                     security-sensitive.

CodeRabbit reached the same conclusion independently on binance-trading-bot#732 — that the PR "gives an unpinned scanner access to a write-scoped job and retained checkout credentials."

Both are correct. The job holds pull-requests: write and security-events: write, and it was installing a floating @latest with lifecycle scripts enabled. Any publish anywhere in the CLI's dependency tree could run arbitrary code inside a write-scoped job on a stranger's runner, with a checkout credential still sitting in .git/config.

A security tool whose own workflow trips a security gate has no argument left to make. Fixed in profullstack/sh1pt: install with --ignore-scripts, render an exact version instead of @latest, and persist-credentials: false on checkout. Verified that scan still runs correctly from an --ignore-scripts install.

2. Ask before sending — capstone asked for it explicitly

Rot127's "please open an issue about this first" is the standard courtesy for unsolicited CI changes, and it costs us nothing. A PR arrives as a decision already made and a diff to review; an issue arrives as a question. Two of the closes ("not planned for now", "not intending to integrate") were project-direction answers that an issue would have surfaced without anyone reviewing a diff.

Proposal: tcfeed pr opens an issue by default and only opens a pull request where the maintainer asks for one. --pr keeps the current behaviour for repos that prefer patches.

3. Say how this differs from CodeQL

The CodeQL objection is real and deserves an answer in the body, because "we already get this from GitHub" is true for a lot of repos and we currently say nothing about it.

The answer should be how it differs, not that it is better. It is not better at what CodeQL does — CodeQL is semantic dataflow analysis and ours is largely pattern matching, which our own output admits (confidence: pattern vs confidence: evidence). Overclaiming to a maintainer who already named CodeQL is how a PR gets closed faster.

What is true and checkable:

• Code scanning and secret scanning are free on public repos, but need paid GitHub Code Security / Secret Protection on private ones. This is MIT and free on both.
• CodeQL covers a fixed language set, and for compiled languages it analyzes only the language with the most source files unless configured otherwise — so a polyglot repo is partly unscanned by default.
• It is report-only and additive; it does not replace anything.

That is a paragraph, not a sales page, and it should end the same way the body already does: closing it is the right answer.

What this does not fix

Three of six closes were "we don't want a third-party integration", and no wording changes that. If the next batch also goes 0-for-N with the issue-first flow, the honest read is that unsolicited CI installs are not a channel that works for large repos, and the tool should aim at repos that ask.

[ralyodio]

Status: all three items are implemented and open for review.

1. The workflow fails security review — profullstack/sh1pt#957. S6505 and S8543 both addressed; --ignore-scripts on the install and persist-credentials: false on checkout. Half of it turned out to be fixed already: #952 pinned the spec on master while the branch was open, so that branch now defers to master's wording and carries only the part master lacks. Rendered into AudioMuse-AI#856, SonarCloud went from 2 MAJOR vulnerabilities to 0 open issues and the gate passes.

2. Ask before sending — #121. tcfeed pr now opens an issue, then the pull request, then waits for the checks and fixes what it recognises as its own. --no-issue and --no-follow are escapes; both stages are on by default. The "asked once" promise covers both channels now, which matters more than it looks: a repository that answers the issue and never gets a pull request has none for the old check to find, so without an issue search a "no" would have been followed by the whole thing again next run.

Worth being straight about one thing — this opens the issue and the pull request together, which is not quite what Rot127 asked for. They wanted discussion before a diff exists. The issue says so outright rather than pretending otherwise: it states that a pull request is being opened alongside, and that closing it and discussing here instead is a fine answer.

3. Say how it differs from CodeQL — #121. Different, not better, opening by conceding that a repository already running CodeQL is not missing much. The two claims it does make are checkable by the reader: code and secret scanning cost money on private repositories, and CodeQL analyses one compiled language by default.

Still true, and still the thing no ordering fixes: three of the six closes were "we don't want a third-party integration."

The one leg not tested end-to-end is a live gh issue create against a repository we have not asked — every repo we own already has the workflow, and using a stranger's as a test fixture is what this issue is about.

[ralyodio]

Correction to the numbers above. "Six went out" was wrong, and wrong in the direction that matters. I counted only the requests that had been answered — gh search prs --state closed — and read that as the whole batch.

The actual standing, from tcfeed check:

Requests open	26
Requests closed	7
Merged	0
Total sent	33

So the headline is not "0-for-6". It is 33 sent, 7 answered, none accepted, 26 still waiting. Two of the seven I had not seen when I opened this:

• discord-go/discord.go#6 — "I'll look into security scanning options in the future, likely GitHub's built-in CodeQL/secret scanning first. Appreciate the transparency on the disclosure." (This is the close that prompted the CodeQL section in feat(tcfeed): ask first, then offer, then clean up after itself #121.)
• rasterm/rasterm#3 — "I'd prefer to keep the CI/security tooling fairly minimal as rasterm is still what I'd call 'experimentally stable', and I'm planning to add fuzzing tailored specifically to rasterm's attack surface later on."

Both are reasoned, courteous, and specific. Neither is a wording problem.

What the corrected numbers change.

The pessimistic read gets weaker: a 7-answer sample is thin, and 26 repositories have not answered at all. The conclusion that "unsolicited CI installs are not a channel that works" is not supported by 7 nos — it needs the 26 to land somewhere first.

The volume concern gets much stronger, and it is now the thing I would look at before sending anything else. 33 open unsolicited pull requests across strangers' repositories is a lot, and prCommand's own docstring says why:

Bulk unsolicited pull requests are against GitHub's acceptable use policy however good the workflow is, and an account that sends them stops being able to send anything.

Nine of the 26 sit at blocked and most report waiting for the maintainer to approve the run — GitHub withholds workflow runs from first-time contributors, so a good share of these have never even executed the thing they are proposing.

And #121 now opens an issue as well as a pull request. That is the right courtesy per repository, but it doubles the footprint per target. A tcfeed pr --all run of 20 is 40 artifacts in other people's repositories.

Suggestion: hold the next batch until some of the 26 resolve. The information worth having is what fraction of quiet requests eventually merge, and sending 20 more before that is known buys nothing and spends account standing to do it. TCFEED_PR_MAX is the dial; the cap it enforces is per-run, not per-week, and nothing currently tracks the latter.