@codyswann/lisa 2.334.0 → 2.335.0

package/plugins/src/base/hooks/sonar-secrets.sh

@@ -0,0 +1,139 @@
+#!/usr/bin/env bash
+#
+# Shared wrapper around `sonar hook <event>` for every agent surface.
+#
+# `sonar integrate <agent>` generates a five-line shim per surface: if `sonar` is
+# on PATH, pipe the hook payload to it and let whatever comes back stand. That is
+# correct for the thing the scanner exists to do — refusing a prompt or a file
+# read that genuinely contains a credential — and wrong for the thing it also
+# does, which is refusing *everything* when the CLI has no token yet:
+#
+#   {"decision":"block","reason":"SonarQube secret scanning is inactive:
+#    not authenticated. Run 'sonar auth login'."}
+#
+# At the shim level that reply is indistinguishable from a real finding, so a
+# workstation that had simply never run the browser login could not submit a
+# prompt at all. Two things are wrong with that, and this wrapper fixes both.
+#
+# 1. The credential is usually already provisioned. A project that declares
+#    SONARQUBE_CLI_TOKEN under `secrets.require` has it in its configured
+#    provider — and the CLI reads only the environment and the OS keychain, so on
+#    a local surface (which deliberately materializes nothing to disk) the value
+#    is present and unreachable at the same time. We resolve it through
+#    lisa-secrets-access, the one sanctioned reader, and only when the CLI says
+#    it needs it.
+#
+# 2. An unauthenticated scanner is a degraded gate, not a breach. This hook is
+#    one of several overlapping layers: secret scanning at commit time and in CI
+#    does not depend on it. Blocking every prompt to protect a redundant layer
+#    trades a certain outage for a hypothetical leak — and the outage lands on
+#    exactly the person least able to diagnose it, since the block fires before
+#    their first prompt is ever seen.
+#
+# A real finding still blocks. Only the "inactive" reply is downgraded, and the
+# distinction is drawn on the reason text the vendor emits, so a detection that
+# arrives while unauthenticated is impossible by construction — in that state the
+# scanner does not scan at all.
+#
+# Usage: sonar-secrets.sh <vendor-event-name>   # hook payload on stdin
+set -uo pipefail
+
+event="${1:-}"
+[ -n "$event" ] || exit 0
+
+# Nothing installed, nothing to enforce. Matches the vendor shim's own guard.
+command -v sonar >/dev/null 2>&1 || exit 0
+
+# An explicit off switch, for bisecting a session that is misbehaving. There is
+# deliberately no way to turn the *blocking* back on from the environment: the
+# decision that a missing token must not stop work belongs in this file, where it
+# is reviewable, not in whatever shell happened to launch the agent.
+[ "${LISA_SONAR_HOOK:-on}" = "off" ] && exit 0
+
+payload="$(cat)"
+
+# The vendor signals its verdict as JSON on stdout and always exits 0, so the
+# exit code carries no information and the reason text is the only channel.
+inactive_marker='secret scanning is inactive'
+
+run_scanner() {
+  printf '%s' "$payload" | sonar hook "$event" 2>/dev/null
+}
+
+is_inactive() {
+  case "$1" in
+    *"$inactive_marker"*) return 0 ;;
+    *) return 1 ;;
+  esac
+}
+
+# Run the resolver with a ceiling, because the provider call crosses the network
+# and this sits in front of every prompt and every file read. `timeout` is not
+# present on a stock macOS, so this is the portable equivalent: start it, poll,
+# give up. Giving up is safe — the caller treats an empty value as "the provider
+# had nothing", which lands on the warn path rather than a block.
+resolve_secret() {
+  local resolver="$1" name="$2" out pid waited=0
+  out="$(mktemp)" || return 0
+  node "$resolver" get "$name" >"$out" 2>/dev/null &
+  pid=$!
+  while kill -0 "$pid" 2>/dev/null; do
+    [ "$waited" -ge 10 ] && { kill -9 "$pid" 2>/dev/null; break; }
+    sleep 1
+    waited=$((waited + 1))
+  done
+  wait "$pid" 2>/dev/null
+  cat "$out"
+  rm -f "$out"
+}
+
+out="$(run_scanner)"
+
+if is_inactive "$out"; then
+  # Where lisa-secrets-access lives depends on how the project receives Lisa.
+  # Claude and Codex get it as an installed plugin, which is not part of a clone;
+  # the agent skill directories and node_modules are what a fresh checkout
+  # actually has. Same search order as the remote-env setup script, including the
+  # `plugins/` rung that exists only in the Lisa monorepo itself.
+  repo_root="${CLAUDE_PROJECT_DIR:-$(git rev-parse --show-toplevel 2>/dev/null || pwd)}"
+  resolver=""
+  for candidate in \
+    "$repo_root/.claude/skills/lisa-secrets-access/scripts/resolve-secret.mjs" \
+    "$repo_root/.agents/skills/lisa-secrets-access/scripts/resolve-secret.mjs" \
+    "$repo_root/.codex/skills/lisa-secrets-access/scripts/resolve-secret.mjs" \
+    "$repo_root/plugins/lisa/skills/lisa-secrets-access/scripts/resolve-secret.mjs" \
+    "$repo_root/node_modules/@codyswann/lisa/plugins/lisa/skills/lisa-secrets-access/scripts/resolve-secret.mjs"; do
+    if [ -f "$candidate" ]; then
+      resolver="$candidate"
+      break
+    fi
+  done
+
+  if [ -n "$resolver" ] && command -v node >/dev/null 2>&1; then
+    token="$(resolve_secret "$resolver" SONARQUBE_CLI_TOKEN)"
+    if [ -n "$token" ]; then
+      # Exported into this process only. Writing it anywhere durable would create
+      # a second live copy of a credential whose single store is the provider —
+      # see the one-store rule in lisa-secrets-access.
+      export SONARQUBE_CLI_TOKEN="$token"
+      org="$(resolve_secret "$resolver" SONARQUBE_CLI_ORG)"
+      [ -n "$org" ] && export SONARQUBE_CLI_ORG="$org"
+      out="$(run_scanner)"
+    fi
+    unset token org
+  fi
+fi
+
+if is_inactive "$out"; then
+  # stderr on a zero exit is advisory in every agent's hook protocol: the user
+  # sees it, the operation proceeds.
+  echo "sonar: local secret scanning is inactive (no token in the environment," >&2
+  echo "  the OS keychain, or the configured secrets provider). Continuing —" >&2
+  echo "  commit-time and CI secret scanning still gate this repository." >&2
+  echo "  To restore it: 'sonar auth login', or store SONARQUBE_CLI_TOKEN in" >&2
+  echo "  the project's secrets provider." >&2
+  exit 0
+fi
+
+[ -n "$out" ] && printf '%s' "$out"
+exit 0

package/plugins/src/base/skills/lisa-setup-sonar/SKILL.md

@@ -80,6 +80,51 @@ MCP config so it launches `sonar run mcp`, authenticated from the same env token
 
 Skip any agent whose CLI is not installed; never wire Kiro or Gemini.
 
+## 4a. Patch the generated shims — required, not optional
+
+Each integrate writes a five-line shim that pipes the hook payload to `sonar hook
+<event>` and passes the verdict through unchanged. That makes an
+**unauthenticated CLI refuse every prompt and every file read**, with a reason
+string that reads exactly like a real finding:
+
+```text
+SonarQube secret scanning is inactive: not authenticated. Run 'sonar auth login'.
+```
+
+The operator most likely to hit it is the one who just installed the CLI and has
+not logged in — so their very first prompt is rejected, before the session can
+say anything useful. Repoint every generated shim at Lisa's wrapper, which keeps
+real findings blocking, resolves `SONARQUBE_CLI_TOKEN` through
+`lisa-secrets-access` when the CLI reports it has none, and degrades the
+still-unauthenticated case to a warning:
+
+```bash
+if ! command -v sonar &> /dev/null; then
+  exit 0
+fi
+here="$(cd -- "$(dirname -- "$0")" && pwd)"
+exec bash "${here}/<relative-path>/scripts/lisa-hooks/sonar-secrets.sh" <vendor-event>
+```
+
+One wrapper serves every surface — it takes the vendor event name as its only
+argument. Known shim locations and their events:
+
+| Agent | Shim | Event |
+| --- | --- | --- |
+| Claude | `.claude/hooks/sonar-secrets/build-scripts/prompt-secrets.sh` | `claude-prompt-submit` |
+| Claude | `.claude/hooks/sonar-secrets/build-scripts/pretool-secrets.sh` | `claude-pre-tool-use` |
+| Codex | `.codex/hooks/sonar-secrets/build-scripts/prompt-secrets.sh` | `codex-prompt-submit` |
+| Copilot | `.github/hooks/sonar-secrets/build-scripts/pretool-secrets.sh` | `copilot-pre-tool-use` |
+| Antigravity | `.agents/sonar/hooks/pretool-secrets.sh` | `antigravity-pre-tool-use` |
+
+Compute the relative path from each shim's own directory rather than assuming a
+depth — Antigravity's is three levels up, the rest are four.
+
+**Re-running an integrate overwrites the shim with the vendor's original**, so
+re-apply this patch whenever you re-run step 4, and say so in the summary. Leave
+a comment at the top of each patched shim naming the wrapper, so the next reader
+does not mistake the delegation for drift.
+
 ## 5. Write non-secret policy config
 
 Merge only non-secret identifiers into committed `.lisa.config.json`, preserving

package/scripts/build-plugins.sh

@@ -112,6 +112,20 @@ for guard in block-no-verify parity-safety-net block-shell-json-parsing \
     chmod +x "$HOST_GUARD_DIR/$guard.sh"
   fi
 done
+# The Sonar hook wrapper, which ships alongside the guards but is not one.
+#
+# The guards above are dispatched by lisa-enforcement-fallback.sh and take a tool
+# payload with no arguments. This one is invoked by the shim that
+# `sonar integrate <agent>` generates, takes the vendor's event name as its only
+# argument, and must therefore stay out of that dispatcher's list — it is copied
+# here because a host project needs it in its checkout for the same reason the
+# guards are, not because it is dispatched the same way.
+if [ -f "$SRC_DIR/base/hooks/sonar-secrets.sh" ]; then
+  mkdir -p "$HOST_GUARD_DIR"
+  cp "$SRC_DIR/base/hooks/sonar-secrets.sh" "$HOST_GUARD_DIR/sonar-secrets.sh"
+  chmod +x "$HOST_GUARD_DIR/sonar-secrets.sh"
+fi
+
 # The dispatcher itself, so a host project gets the identical entry point.
 # Guarded like the ratchet above: this script is also run against isolated
 # fixtures that carry a source tree but none of the repository's own scripts,

package/scripts/lisa-enforcement-fallback.sh

@@ -24,16 +24,39 @@ payload="$(cat)"
 repo_root="${CLAUDE_PROJECT_DIR:-$(git rev-parse --show-toplevel 2>/dev/null)}"
 [ -n "$repo_root" ] || exit 0
 
-# Skip when the plugin is installed, so a developer machine does not run every
-# guard twice and print every refusal twice. Absence is the interesting case and
-# the only one this exists for.
+# There is deliberately no skip here, and that is the whole point.
 #
-# Read from the plugin registry rather than from CLAUDE_PLUGIN_ROOT: that
-# variable is set for plugin hooks, and this hook is by definition not one.
-installed="${CLAUDE_CONFIG_DIR:-$HOME/.claude}/plugins/installed_plugins.json"
-if [ -f "$installed" ] && grep -q '"lisa@lisa"' "$installed" 2>/dev/null; then
-  exit 0
-fi
+# This used to stand down when `installed_plugins.json` mentioned `lisa@lisa`,
+# to avoid running every guard twice on a developer machine. The question that
+# has to be answered is "are the plugin's guards running in this session?" and
+# the file being consulted answers "has this plugin ever been installed, for any
+# project, on this machine?". Those come apart three ways, and in each one both
+# layers were off:
+#
+#   - Project-blind. The registry is keyed by plugin with an array of per-project
+#     entries, so the grep matched the key. One project installing Lisa disabled
+#     the fallback for every other project on the machine.
+#   - Enablement-blind. `enabledPlugins` can set a plugin to false without
+#     removing its registry entry, so the plugin guards were off while this file
+#     believed they were on.
+#   - Session-blind. Hooks load at session start; the registry is written on any
+#     install or update. A plugin updated four minutes into a session leaves the
+#     registry saying "installed" for the rest of it, with no plugin hooks
+#     loaded. That is the one that was caught in the wild: a write to AGENTS.md
+#     went through in a session where both guard copies exit 2 for that exact
+#     payload.
+#
+# The first two are fixable with a better lookup. The third is not: plugin-hook
+# liveness is not observable from a repository hook. CLAUDE_PLUGIN_ROOT is set
+# only for plugin hooks, and nothing on disk distinguishes "registered" from
+# "loaded into this session". Any check against a file answers a different
+# question and will drift from the real one again.
+#
+# So the guards run unconditionally. On a machine where the plugin hooks are also
+# live that costs a duplicated sweep (~170ms) and a refusal printed twice, and
+# that is the correct trade against enforcement silently switching itself off.
+# Recovering it belongs in the guards — a marker keyed on session and payload, so
+# whichever layer fires first does the work — not in a liveness guess here.
 
 # Where the guards live depends on which repository this is.
 #