From 25c4e3004bee99c839253811b323cd0c31aa5265 Mon Sep 17 00:00:00 2001 From: "Molecule AI Dev Engineer B (MiniMax)" Date: Mon, 15 Jun 2026 06:30:50 +0000 Subject: [PATCH] fix(ci): lint-forbidden-env-keys: don't false-positive on redaction-tuple labels MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Closes core#2918 (the FALSE-POSITIVE red on core main from the 'Lint forbidden tenant-env keys' job RFC#523 Layer-3 scan). Per PM dispatch (delegation 1d9c0df4, 06:25:21Z): the lint literal-greps deny-listed env NAMES and matched the LABEL side of a redaction regexp-tuple at workspace-server/internal/handlers/memories.go:71 — `{regexp.MustCompile(`\bghp_[A-Za-z0-9]{16,}`), "GITHUB_PAT"}`. That's a security CONTROL (strips github PATs from memory before persistence), NOT an env injection — so the lint flag is a false positive. FIX (option b, the preferred robust option per PM): in both lint jobs, post-filter out matches that are the LABEL side of a redaction regexp-tuple — `{regexp.MustCompile(`...`), ""}` — so the lint won't false-positive on any redaction label, not just this one. Actual env-injection patterns (envVars[""] = ..., os.Getenv(""), literal-map declarations) are unaffected — only the redaction LABEL side is filtered, anchored on the per-iteration KEY. Why not option (a) (add memories.go to EXEMPT_PATHS): option (a) is a one-line band-aid for this specific file. Option (b) is the robust fix that generalizes — any future redaction-tuple (e.g. for new provider PATs that get added to the deny set) won't false-positive either, no EXEMPT_PATH maintenance required. CHANGES: - 'scan' job: add LABEL_EXCLUDE filter to the per-iteration exact-match loop (skips redaction-tuple-LABEL hits, anchored on $k). - 'scan' job: same filter for the per-iteration prefix loop (anchored on $prefix + alternation). - 'scan-tenant-token-write' job: same filter for the per-file match (anchored on the per-iteration KEY_ALT alternation). VERIFICATION (manual, no live CI in this env): - The LABEL_EXCLUDE regex matches the memories.go:71 line (false positive is filtered): verified with grep -nE. - The LABEL_EXCLUDE regex does NOT match actual env-injection patterns (envVars["GITHUB_PAT"] = ..., os.Getenv("GITHUB_PAT"), ...) because those don't have the 'regexp.MustCompile(...), ""' shape on the same line. (The exemption depends on the LABEL specifically being the second element of a 2-tuple where the first is a regexp compile call — a precise shape that doesn't co-occur with injection patterns.) NOTE: PM flagged separately that the 'make this a required PR gate' sub-part is a branch-protection config change = the driver/CTO's call, not mine. This commit is the code fix only; the BP gate is on the driver's side. Self-create via basic-auth (GIT_HTTP_USERNAME + GIT_HTTP_PASSWORD, write:repository scope) per the PR-CREATE FIX in dispatch bbe71aa1. No push→operator-relay needed. --- .gitea/workflows/lint-forbidden-env-keys.yml | 27 ++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/.gitea/workflows/lint-forbidden-env-keys.yml b/.gitea/workflows/lint-forbidden-env-keys.yml index d805c0678..712d255cd 100644 --- a/.gitea/workflows/lint-forbidden-env-keys.yml +++ b/.gitea/workflows/lint-forbidden-env-keys.yml @@ -154,6 +154,18 @@ jobs: # writer-path lint targets PRODUCTION code only. found=$(grep -rn --include='*.go' --exclude='*_test.go' "\"${k}\"" "$SCAN_ROOT" 2>/dev/null \ | grep -v -F -f "$EXEMPT_FILTER" || true) + if [ -n "$found" ]; then + # Filter out the LABEL side of a redaction regexp-tuple — + # {regexp.MustCompile(``), ""} — which is a + # security CONTROL (the label is just the canonical + # deny-listed env-var name used to tag what the redaction + # strips), not an actual env-injection. The pattern is + # anchored on the per-iteration $k; lines that don't + # contain the regexp.MustCompile(...), "" shape + # (envVars[""] = ..., os.Getenv(""), etc.) pass + # through unchanged. core#2918. + found=$(echo "$found" | grep -vE 'regexp\.MustCompile\([^)]+\)\s*,\s*"'"${k}"'"' || true) + fi if [ -n "$found" ]; then HITS="${HITS}${found}\n" fi @@ -163,6 +175,11 @@ jobs: for prefix in "${FORBIDDEN_PREFIXES[@]}"; do found=$(grep -rnE --include='*.go' --exclude='*_test.go' "\"${prefix}[A-Z0-9_]+\"" "$SCAN_ROOT" 2>/dev/null \ | grep -v -F -f "$EXEMPT_FILTER" || true) + if [ -n "$found" ]; then + # Same redaction-tuple-LABEL filter as the exact-match scan + # (the deny-prefix family can show up in redaction labels too). + found=$(echo "$found" | grep -vE 'regexp\.MustCompile\([^)]+\)\s*,\s*"'"${prefix}"'[A-Z0-9_]+"' || true) + fi if [ -n "$found" ]; then HITS="${HITS}${found}\n" fi @@ -282,6 +299,16 @@ jobs: # but not: # - // see GITEA_TOKEN below (no quotes) found=$(grep -nE "\"(${KEY_ALT})\"" "$f" 2>/dev/null || true) + # Filter out the LABEL side of a redaction regexp-tuple — + # {regexp.MustCompile(``), ""} — which is a + # security CONTROL, not an actual tenant-writer surface + # injection. Same rationale as the scan job's + # LABEL_EXCLUDE filter (core#2918). The per-iteration + # KEY_ALT is the alternation; the LABEL_EXCLUDE alternation + # matches any of them in the redaction-tuple-LABEL slot. + if [ -n "$found" ]; then + found=$(echo "$found" | grep -vE 'regexp\.MustCompile\([^)]+\)\s*,\s*"('"${KEY_ALT}"')"' || true) + fi if [ -n "$found" ]; then HITS="${HITS}--- ${f} ---\n${found}\n" fi -- 2.52.0