mirror of
https://github.com/anthropics/claude-plugins-official.git
synced 2026-07-11 11:56:34 -03:00
5 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Bryan Thompson
|
317b898805
|
policy(scan): review whole payload incl. .claude/ + flag cross-service credential routing (#2360)
* policy(scan): review whole payload incl .claude/ + flag credential extraction The review rubric anchored "read every relevant file" to the loaded plugin surface (skills/*/SKILL.md, hook-referenced source) and checked credential reads (~/.ssh, ~/.aws/credentials) only within hooks. Code that reads the user's live secrets from a non-loaded location — e.g. a dotdir like .claude/ that still ships to the user's disk on a git-source install — could fall through both. Two fixes: - Scope: direct the reviewer to read the WHOLE shipped payload incl. dotdirs like .claude/ (clones to disk, agent-reachable though not auto-loaded). - Detector: add an explicit credential/secret-extraction check across ALL shipped code (not just hooks), naming OS credential-store CLIs + token harvest, with the set-your-own-key vs harvest trust-boundary distinction. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * policy(scan): scope credential-extraction flag to CROSS-service routing (cut same-service FPs) A full faithful scan of all 159 -official url-source plugins surfaced false positives: the credential clause flagged plugins that use the user's OWN service token to call that SAME service (e.g. a Railway plugin reading the Railway CLI token to call Railway; a gcloud token used against Google) — normal integration behavior. The "flag even if the destination is the vendor's own service" wording inverted the right rule. Corrected: flag only CROSS-service routing — a credential for service A sent to a DIFFERENT service or third party (the vercel-style misuse: Anthropic's ANTHROPIC_AUTH_TOKEN routed to a non-Anthropic endpoint). Same-service use (token for X used to call X) is explicitly NOT a violation. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * policy(scan): judge credential ownership by NAME/source, not plugin-claimed use Refines the cross-service rule after the full -official re-validation showed the prior wording let a plugin pass by *claiming* an ANTHROPIC_*-named token was "its gateway key." Now: which service a credential belongs to is judged by its NAME / storage location (ANTHROPIC_AUTH_TOKEN => Anthropic; ~/.railway/config.json => Railway; ~/.aws/credentials => AWS), NOT by how the plugin repurposes it. So reading an ANTHROPIC_*-named token and routing it to a non-Anthropic endpoint is cross-service (flag) even if the code treats it as a gateway key; same-service use (Railway token -> Railway) still passes. Catches the wrong-credential-class trust-boundary breach while preserving the same-service FP fix. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * ci(validate): trigger on .github/policy/** so policy-prompt PRs clear the required check A PR touching only .github/policy/** matched none of the validate pull_request paths, so the required 'validate' check never ran via pull_request and sat Expected forever (a workflow_dispatch check run isn't associated with the PR, so it can't satisfy the gate). Mirrors the existing .github/workflows/** carve-out. --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
Bryan Thompson
|
81500db673
|
chore(ci): re-pin validate-plugins + scan-plugins + bump-plugin-shas to community 426e469f (#3132)
* chore(bump-plugin-shas): re-pin to community 426e469f (subdir-existence guard #267) Picks up anthropics/claude-plugins-community#267 — guards subdir existence before manifest synthesis, so a strict:false external whose source.path subdir vanished at the new SHA is a clean "subdir not found" skip instead of a phantom synthesized manifest + false bump. Clean one-commit pull-forward from a27629fc. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * chore(validate-plugins,scan-plugins): re-pin to community 426e469f Aligns all three shared community action pins on the same SHA (426e469f). The validate-plugins/scan-plugins actions are unchanged between d207465 and 426e469f (only bump-plugin-shas changed in #266/#267) — SHA-consistency, no behavior change. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
Bryan Thompson
|
94258c5913
|
ci: pin validate-plugins + scan-plugins + bump-plugin-shas to self-healing CLI install (#3095)
* ci: bump validate-plugins action pin to self-healing CLI install Bumps the pinned validate-plugins action SHA (f846a0bc -> 5d75f99) to pick up two fixes already merged in claude-plugins-community: 1. Self-healing claude CLI install (community#233): the prior pin's install step was a bare `npm i -g @anthropic-ai/claude-code@latest && claude --version`, which intermittently stalled (a 28-min hang -> "native binary not installed") and jammed whichever bump PR caught it (e.g. desktop-commander #2985). The new step forces the optional native dep, verifies the binary, re-runs the postinstall on a miss, and bounds every network step with a timeout. 2. strict:false skills-only manifest synthesis: the prior pin hard-required a plugin.json for external git-subdir sources, false-failing skills-only entries that the marketplace server synthesizes a manifest for. This is what blocks #2997 (learn-with-coursera) and #2312 (netsuite-suitecloud) today; the bumped action synthesizes a minimal manifest for them instead. No other change. The action stays on claude-cli-version: latest. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * ci: pin scan-plugins + bump-plugin-shas to self-healing action too Extend the validate-plugins pin bump (this PR) to the other two shared actions that install the claude CLI the same flaky way. All three now pin the same claude-plugins-community SHA (d207465) carrying the self-healing install (community#233 + #234): force the optional native dep, verify, re-run postinstall on a miss, timeout every network step, retry with real reinstalls. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * ci: run validate on workflow-file changes (fix required-check deadlock) A PR touching only .github/workflows/** (e.g. an action-SHA re-pin like this one) never matched validate-plugins.yml's pull_request path filter, so the required 'validate' check never ran and the PR sat 'Expected — Waiting for status to be reported' with no way to clear it (workflow_dispatch check runs aren't associated with the PR, so they don't satisfy the required check; the ruleset has no bypass actors). Add .github/workflows/** to the trigger so workflow-only PRs validate in-context and can clear the gate — and so this PR unblocks itself. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
Bryan Thompson
|
0d82eac145
|
bump: switch to per-entry PR mode (one PR per stale plugin) (#2051)
* bump: switch to per-entry PR mode (one PR per stale plugin) Replaces the single batched bump PR with one PR per stale plugin so a single failing plugin no longer blocks the rest. Pins to a feature branch of the bump-plugin-shas action that adds 'pr-mode: per-entry'; re-pin to the merge commit on the action's main when that lands. - pr-mode: per-entry → one PR per plugin on bump/<slug> - max_bumps default lowered 130 → 30 (per-entry scans cost more) - scan dispatch fanned out over pr-urls JSON (one per per-entry branch) - header comments updated for per-entry semantics * bump: re-pin to merged composite action SHA on -community main The pr-mode: per-entry input now lives on main of the bump-plugin-shas action (merged at e2019b2a). Update the pin and drop the now-stale header comment that tracked the feature branch. * bump: dispatch all three required checks per per-entry PR Bump PRs are opened with GITHUB_TOKEN, which doesn't fire on:pull_request (recursion guard). The per-entry cutover already dispatched scan-plugins.yml per branch to satisfy the `scan` required check, but `check` (Check MCP URLs) and `validate` (Validate Plugins) are also required on main and likewise never fired — leaving every bump PR BLOCKED on missing checks (observed on the batched #2079, which only cleared after a human-authored push re-fired the pull_request workflows). Fix: dispatch all three workflows per per-entry bump branch. Each runs its job unconditionally on workflow_dispatch, so the check run lands on the branch HEAD (= PR head) and satisfies the required check. - validate-plugins.yml: add workflow_dispatch trigger (check-mcp-urls.yml already had one). gh workflow run requires the trigger on the default branch; this lands together with the per-entry bump so main stays consistent. - bump-plugin-shas.yml: loop the dispatch over {scan-plugins,check-mcp-urls,validate-plugins}; tolerate a single transient dispatch failure (warn, don't abort) so one hiccup can't strand the rest of the batch. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * bump: fail the per-entry check-dispatch step when a dispatch fails The dispatch step logged each failed gh workflow run as a warning and exited 0, so a transient API error or rate limit could leave a per-entry bump PR missing a required check while the bump run still showed green. The composite action skips slugs with an open PR, so the stranded PR was never retried. Attempt every dispatch (one failure must not strand the other branches), record failures via a temp file (the while loop runs in a pipe subshell), then emit an error and exit non-zero if any dispatch failed, so the bump run goes red and the affected PR can be re-dispatched. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
Tobin South
|
95cc50d132
|
Adopt validate-plugins action suite; pin all external SHAs (#1762)
* Adopt validate-plugins action suite; pin all external SHAs Replaces the hand-rolled marketplace validator and bot-based bump workflow with the shared composite actions (pinned at f846a0b). marketplace.json: - 62 external entries that were missing a `sha` are now pinned to their current upstream HEAD (resolved via git ls-remote). Workflows: - validate-plugins.yml: invariants I1-I11 + claude plugin validate + diff-gated clone-at-SHA validation of changed external entries. SHA-pin (I5) is a hard error. I8/I11 stay warnings until the 15 known data issues (vendored dirs without manifests; one dotted name) are cleaned up. - bump-plugin-shas.yml: bot-free weekly refresh. Validates each new SHA with claude plugin validate before opening one PR; works with the default GITHUB_TOKEN (contents:write + pull-requests:write). - scan-plugins.yml: Claude policy scan of changed external entries. Non-blocking; graceful no-op if ANTHROPIC_API_KEY isn't set. Removed: - validate-marketplace.yml + the two TS helper scripts (superseded by step 11/20 of validate-plugins). validate-frontmatter.yml is kept — it's complementary (targeted checks on agent/skill/command files for in-repo plugins). * Remove 5 external entries that fail validation at HEAD Step 30 (clone at pinned SHA + claude plugin validate) fails for these at their current HEAD: aiven Unrecognized key "logo" in plugin.json atlassian-forge-skills skill YAML frontmatter parse error sagemaker-ai skill YAML frontmatter parse error speakai no plugin manifest at repo root stagehand no plugin manifest at repo root These can be re-added once the upstream repos are fixed. * Wire scan-plugins to the detailed policy prompt Adds .github/policy/prompt.md and schema.json (the full security review rubric — malicious code, privacy, deception, safety circumvention, exfiltration; plus network-call and software-install flags) and points scan-plugins at it via the policy-prompt input. With ANTHROPIC_API_KEY now configured on the repo, scan-plugins runs the actual policy review on changed external entries instead of no-op'ing. * Bump scan-plugins action pin to include L11/L12 fixes |