added 260907 version of worker toolkit
This commit is contained in:
@@ -0,0 +1,92 @@
|
||||
---
|
||||
name: detector-credential-leakage
|
||||
description: |
|
||||
Self-check whether your submission ships a credential inside its authored
|
||||
surfaces — above all `environment/workspace.patch`. Mainly one job: find
|
||||
leaked keys, tokens and secrets. Deterministic pattern checks hard-flag your
|
||||
authoring environment's own env vars (`ANTHROPIC_API_KEY`,
|
||||
`ANTHROPIC_BASE_URL`, `USER_ID` as an env assignment) and well-known secret
|
||||
shapes (`sk-ant-…`, AWS `AKIA…`, GitHub `ghp_…`, Google `AIza…`, Stripe
|
||||
secret keys, bearer tokens, private-key blocks, URL-embedded passwords) on
|
||||
lines your patch adds; a placeholder test then clears dummies, `.env.example`
|
||||
files, dev defaults and code identifiers. A `credential-leak` must be fixed
|
||||
before submitting AND the key reported for rotation, since removing the line
|
||||
doesn't un-ship it; `suspicious-content` is advisory. A second, narrow check
|
||||
flags an absolute path from your own machine that continues into your checkout
|
||||
on a line your patch adds (`/home/you/.../worker-toolkit-x/repo/...`) — a
|
||||
patch is repo-relative, so such a path only gets in by accident: that's
|
||||
`internal-leak`, fix it before submitting, nothing to rotate. The report never
|
||||
reproduces secret values. Reads workspace.patch (+ Dockerfile,
|
||||
instruction.md, tests/*.md); runs before or after reference runs exist.
|
||||
allowed-tools: Bash, Read, Write
|
||||
---
|
||||
|
||||
# Credential-leakage detector
|
||||
|
||||
This skill checks one of your tasks for **a leaked credential** — a key, token
|
||||
or secret swept out of your authoring environment into the submission's
|
||||
authored surfaces, above all `environment/workspace.patch`. Everything your
|
||||
patch adds ships to everyone downstream, so a leaked key is compromised the
|
||||
moment you submit, and scrubbing it afterwards doesn't undo that. It also
|
||||
catches one closely-related shape: an absolute path from your own machine.
|
||||
|
||||
The failure shapes to catch:
|
||||
|
||||
- **Your toolkit `.env`** — your personal `ANTHROPIC_API_KEY`,
|
||||
`ANTHROPIC_BASE_URL` and `USER_ID` landing in the workspace as a new `.env`
|
||||
file, a `.env.bak-*` backup, or a symlink to `/home/<you>/.env`.
|
||||
- **Any real third-party secret** the patch adds — an AWS or Google key, a
|
||||
GitHub token, a Stripe secret key, a private-key block, a captured request
|
||||
carrying a live `Authorization: Bearer …`, a database URL with the password
|
||||
embedded.
|
||||
- **An absolute path from your machine into your checkout**, on a line your
|
||||
patch adds — `/home/you/…/worker-toolkit-<repo>/repo/app/foo.rb`. A patch is
|
||||
repo-relative by construction, so this only ever gets in by accident: a
|
||||
coverage report keyed by your file paths, or a helper script with your
|
||||
checkout hardcoded. It ships your username and directory layout to everyone
|
||||
downstream. Rare — 2 in 350 patches.
|
||||
|
||||
What *doesn't* trip this check: placeholder and example values (`.env.example`
|
||||
with dummies, `sk-ant-...` as a literal template), dev defaults
|
||||
(`POSTGRES_PASSWORD=postgres` in a local docker-compose), code identifiers
|
||||
(`USER_ID = 4958` as a test constant, or any variable merely *named* `SECRET`
|
||||
or `TOKEN`), and secrets on context or removed lines — those belong to the
|
||||
source repo, not to you.
|
||||
|
||||
Nor do generic paths that name no person and no checkout — `/home/runner/work/…`
|
||||
in a CI workflow, `/home/ubuntu/<app>` in a deploy config, `/home/app/…` in a
|
||||
compose volume — which real repos legitimately commit.
|
||||
|
||||
Also out of scope, and never reported here: authoring artifacts
|
||||
(`.raccoon-setup-done`, `.claude/settings.local.json`, stray logs) and patch
|
||||
content that simply doesn't relate to the task.
|
||||
|
||||
Read these before deciding:
|
||||
|
||||
1. `.claude/skills/_detector-worker-shell.md` — where to write the report and how to handle re-runs.
|
||||
2. `.claude/skills/detector-credential-leakage/core.md` — the deterministic pattern checks to run, the placeholder test, the redaction rule (never quote a secret value), what is NOT a finding, the out-of-scope list, verdict enums, and the body schema.
|
||||
|
||||
Compose the report per the schema in `core.md` and write it per `_detector-worker-shell.md`.
|
||||
|
||||
## Acting on the verdict
|
||||
|
||||
- **`clean`** — nothing your patch adds looks like a credential. Good, move on.
|
||||
This is the normal answer.
|
||||
- **`suspicious-content`** — no confirmed credential, but something
|
||||
credential-shaped couldn't be resolved: a captured request with a real (if
|
||||
low-sensitivity) token, a config file of credential-shaped values. Replace
|
||||
the value with a placeholder, drop the file, or satisfy yourself it's
|
||||
genuinely scenario material.
|
||||
- **`credential-leak`** — a real credential (or your authoring env vars) is in
|
||||
the patch. Act before submitting: (1) remove the material and regenerate the
|
||||
patch with `bash scripts/check-workspace-sync.sh --update-patch
|
||||
harbor-tasks/<slug>`; (2) re-run this detector to confirm it's gone;
|
||||
(3) report the leaked value through your support channel so it can be
|
||||
rotated — scrubbing the patch does not un-ship a key that already left your
|
||||
machine in an earlier submission.
|
||||
- **`internal-leak`** — your patch adds an absolute path from your own machine
|
||||
into your checkout. Fix before submitting: remove or relativize the path (or
|
||||
drop the file, if it's a generated artifact like a coverage report),
|
||||
regenerate the patch, and re-run this detector. Nothing to rotate.
|
||||
- **`not-applicable`** — there's no workspace patch to assess yet. Build the
|
||||
workspace first.
|
||||
Reference in New Issue
Block a user