@opengsd/gsd-core 1.12.0 → 1.13.0

package/hooks/dist/lib/git-cmd.js

@@ -180,4 +180,213 @@ function isGitSubcommand(cmd, sub) {
   return tokens[subIdx] === sub;
 }
 
-module.exports = { isGitSubcommand, tokenize, extractBranchArgument, skipToSubcommand };
+/**
+ * Resolve a `-m` message argument to its SUBJECT — the first line of the commit
+ * message — resolving the command-substituted heredoc form to the heredoc
+ * BODY's first line.
+ *
+ * PURE STRING FUNCTION. It deliberately does NOT tokenize or walk the command
+ * line: selecting *which* argument is the message stays with the caller, exactly
+ * as before, so this cannot change which commands are validated. An earlier
+ * revision of this fix did walk tokens and regressed four separate cases —
+ * `git commit -- -m WIP` (a pathspec), `git commit --amend && echo -m WIP` (a
+ * later command's flag), `-m "" --allow-empty-message` (the scanner drops empty
+ * tokens, so the following flag became the subject), and unquoted
+ * `git commit -m WIP`. All were allowed upstream and would have started being
+ * blocked. Reported in review of #3802.
+ *
+ * The defect this DOES fix: `gsd-validate-commit.sh` captured the message with
+ * `-m[[:space:]]+"([^"]+)"`, and bash `[^"]` matches newlines, so the widely
+ * used agent-authored commit idiom
+ *
+ *     git commit -m "$(cat <<'EOF'
+ *     feat(auth): add login flow
+ *     EOF
+ *     )"
+ *
+ * captured the whole span up to the final quote at `)"`. Taking its first line
+ * yielded the literal `$(cat <<'EOF'`, which can never satisfy Conventional
+ * Commits, so every heredoc-form commit was blocked regardless of its message.
+ *
+ * Recognition is anchored at BOTH ends and requires a command substitution, so
+ * an ordinary message merely CONTAINING — or ending in — `<<WORD` is not
+ * mistaken for an opener. Without the `^\$\(` anchor,
+ * `-m "WIP notes <<EOF\nfix: smuggled subject"` resolved to the second line and
+ * ALLOWED a non-conforming commit: an enforcement bypass, not just a
+ * misclassification (review of #3802).
+ *
+ * NOT resolved, by design: an UNQUOTED delimiter (`<<EOF`). bash expands `$var`
+ * and `$(...)` in that body, so the literal text here is not what git receives.
+ * An earlier revision resolved it anyway and called the gap "the same
+ * pre-existing limit as expansions in a plain `-m` argument" — that framing was
+ * wrong on both halves: on base the whole heredoc form was blocked, so this fix
+ * CREATED the path, and it dodged the length gate as well as the format gate.
+ * See the expansion guard in the body (review of #3816, round 4).
+ *
+ * KNOWN LIMIT: the DOUBLE-QUOTED delimiter spelling (`<<"EOF"`) is resolvable
+ * here but unreachable through the caller — `gsd-validate-commit.sh`'s
+ * double-quoted `-m` capture stops at the first `"`, which in that spelling is
+ * the delimiter's own quote, so the resolver only ever sees a truncated opener
+ * and the commit stays blocked. Its single-quoted `-m` capture DOES deliver the
+ * spelling intact, which is why an earlier revision's claim of unreachability
+ * was false; the caller now gates the resolver on the double-quoted arm alone
+ * (review of #3816, round 4), so the claim holds again — for that reason, not
+ * by luck. That is the pre-fix behaviour for the whole form (fail closed, a
+ * false positive on one rare spelling), and widening the bash capture to span
+ * inner quotes would change what is captured for EVERY message containing one —
+ * a regression class this fix deliberately does not touch (Codex review of
+ * #3816). The same capture truncation blocks a `"` in the SUBJECT LINE itself,
+ * where it lands inside the line being measured. It does NOT block a `"` on a
+ * later body line: the subject is already complete before the truncation point,
+ * so that message resolves and is allowed (measured; an earlier revision of this
+ * comment and of the changeset claimed a `"` ANYWHERE blocked, which is false —
+ * Codex review of #3816, round 4). The truncation guard below is what keeps the
+ * unmeasurable half fail-closed. Two more legal-but-unrecognized spellings
+ * stay blocked the same fail-closed way: an env-prefixed cat
+ * (`$(A=1 cat <<'EOF'`) and an option-terminated cat (`$(cat -- <<'EOF'`) —
+ * recognizing either would mean modelling bash prefix words here, cost with
+ * no reported user (review of #3816, round 3).
+ *
+ * @param {string} messageArg - the raw `-m` argument, already selected by the caller
+ * @returns {string} the subject to validate
+ */
+function resolveCommitSubject(messageArg) {
+  // CRLF-tolerant split. With a bare split('\n') every body line kept its \r,
+  // so `body.indexOf(delimiter)` never matched on CRLF input: the truncation
+  // guard was inert, an empty CRLF message resolved to 'EOF\r' instead of '',
+  // and a real 72-char subject measured 73 (review of #3816). Splitting on
+  // /\r?\n/ is the repo-wide remedy for this recurring defect class.
+  const lines = String(messageArg == null ? '' : messageArg).split(/\r?\n/);
+  // The path prefix is a PATH-CHARACTER class, not \S*: `\S*` accepted
+  // `id;/bin/cat`, so `$(id;/bin/cat <<'EOF' ...` was resolved to its heredoc
+  // body while bash actually runs `id` first and git's real subject is `id`'s
+  // OUTPUT — an enforcement bypass (Codex review of #3816). A prefix carrying
+  // any shell metacharacter now fails recognition, which falls back to the
+  // opener line and the format gate: fail closed, exactly the pre-fix
+  // behaviour for the whole form.
+  //
+  // Whitespace inside the recognition is ASCII space/tab — [ \t], never \s —
+  // because JavaScript \s includes Unicode whitespace bash does NOT split on:
+  // `$(<NBSP>/bin/cat <<'EOF'` was recognized here while bash reads
+  // `<NBSP>/bin/cat` as the executable NAME, so recognition claimed a
+  // substitution that does not run cat (Codex review of #3816, round 2). The
+  // same ASCII rule as the blank-line skip below, for the same reason.
+  // `cat[ \t]*<<`, not `+`: bash accepts `cat<<'EOF'` with no space (review of
+  // #3816, round 3), and recognizing it costs nothing — the token before `<<`
+  // is still literally `cat`.
+  //
+  // The path prefix must be ABSOLUTE (Codex review of #3816, round 4). The old
+  // `[\w./-]*\/` also accepted `./cat` and `../evil/cat`, so a relative
+  // executable that merely ENDS in `cat` was trusted to echo its stdin: with a
+  // planted `../evil/cat` printing `WIP injected`, the resolver validated the
+  // heredoc body while git's real subject was `WIP injected` (measured
+  // base=2 -> head=0 against a real commit). Requiring `/` up front costs
+  // nothing real — `/bin/cat` and a bare `cat` both still resolve.
+  //
+  // AN ABSOLUTE PATH IS NOT AN IDENTITY EITHER (independent review of #3816,
+  // round 8). Round 4 stopped at "must be absolute", so any absolute path
+  // ENDING in `/cat` was still trusted to echo its stdin — the very thing the
+  // round-4 reasoning rejected one spelling earlier. With an executable at
+  // `/some/scratch/dir/cat` printing `WIP injected`, the resolver validated
+  // the conforming heredoc body while git's real subject was `WIP injected`
+  // (measured on bash 3.2.57 and 5.3.15 against a real commit: hook exit 0,
+  // `git cat-file -p` subject `WIP injected`, while the same command through
+  // `./cat` was already refused). The prefix is now the canonical system
+  // locations, which is the only claim a string can support. `/usr/local/bin`
+  // is deliberately excluded: it is user-writable on ordinary machines, which
+  // is the plantable case this guard exists for.
+  //
+  // RESIDUAL, not fixable from a string: a bare `cat` shadowed earlier on PATH
+  // has the same effect and is indistinguishable here. It is also not a
+  // meaningful boundary — anyone who can plant an executable on PATH can run
+  // `git commit` directly — so this hook stays an authoring guard, not a
+  // security control.
+  //
+  // The delimiter alternatives are split so the BARE spelling is its own group:
+  // `\\(...)` (backslash-quoted) and `(...)` (bare) were one `\\?(...)` branch,
+  // which conflated the only two spellings that differ in bash. See the
+  // expansion guard below.
+  const opener = /^\$\([ \t]*(?:\/(?:usr\/)?bin\/)?cat[ \t]*<<(-?)[ \t]*(?:'([^']+)'|"([^"]+)"|\\([^\s'"();|&<>\\]+)|([^\s'"();|&<>\\]+))[ \t]*$/
+    .exec(lines[0]);
+  if (!opener) return lines[0];
+
+  // EXPANSION GUARD (review of #3816, round 4 — BLOCKER). Only `<<'D'`, `<<"D"`
+  // and `<<\D` suppress expansion. A BARE `<<D` is expanded by bash, so the body
+  // captured here is NOT the text git receives, and measuring it is an
+  // enforcement bypass in both gates at once:
+  //
+  //     -m "$(cat <<EOF\nfeat: $UNSET_VAR\nEOF\n)"   git gets `feat:`  -> format gate dodged
+  //     -m "$(cat <<EOF\nfeat: ${LONG}\nEOF\n)"      git gets any length -> length gate dodged
+  //
+  // Both measured base=2 -> head=0 against the real hook. This is NOT the
+  // pre-existing plain-`-m` expansion limit an earlier revision claimed it was:
+  // on base the whole heredoc form was blocked, so no expansion inside a body
+  // ever reached an allow — this fix created the path, and closes it here.
+  // Same rule every other guard in this function follows: when the real subject
+  // cannot be known, fall back to the opener line, which fails the format gate.
+  if (opener[5]) return lines[0];
+
+  // `<<-` strips leading TABS from every body line, including the terminator.
+  const stripTabs = opener[1] === '-';
+  const delimiter = opener[2] || opener[3] || opener[4];
+  const body = lines.slice(1).map((l) => (stripTabs ? l.replace(/^\t+/, '') : l));
+
+  // TRUNCATION GUARD. The capture that produced this argument stops at the first
+  // `"`, so a message containing one arrives here missing its tail — and its
+  // terminator. Resolving anyway would hand the length gate a PREFIX of the real
+  // subject and let an over-long message through, an enforcement hole that did
+  // not exist before this fix (review of #3802). A body with no terminator is
+  // therefore not resolved at all: returning the opener line fails the format
+  // gate, which is exactly what this whole form did before the fix. The fix
+  // applies where the capture is complete and changes nothing where it is not.
+  const end = body.indexOf(delimiter);
+
+  // POST-TERMINATOR GUARD (review of #3816, round 3 — BLOCKER). Everything
+  // after the terminator is still part of the real message once bash
+  // substitutes: `-m "$(cat <<'EOF'\nfeat: ok\nEOF\n) <200 a's>"` expands to a
+  // single 200+ char subject, but discarding the tail measured 8 and DODGED
+  // COMMIT_SUBJECT_TOO_LONG — the same prefix-measurement class the truncation
+  // guard below exists for, missed on the other side of the terminator. The
+  // canonical idiom's tail is exactly one closing-paren line; anything else
+  // means the substitution is composed with more text, so fall back to the
+  // opener line — blocked, the pre-fix behaviour for the whole form.
+  if (end !== -1) {
+    const tail = body.slice(end + 1);
+    if (tail.length !== 1 || !/^[ \t]*\)[ \t]*$/.test(tail[0])) return lines[0];
+  }
+
+  // git's default `cleanup=whitespace` strips leading blank lines, so the subject
+  // is the first NON-EMPTY body line, not blindly the first one. Taking lines[1]
+  // returned '' for a body that starts blank and falsely blocked a conforming
+  // commit — the very defect class #3802 reports (review of #3802).
+  const scan = end === -1 ? body : body.slice(0, end);
+  // "Blank" is git's ASCII definition — space and tab — never JavaScript's
+  // trim(), whose Unicode whitespace class skips lines git KEEPS: a body whose
+  // first line is a NBSP resolved to the SECOND line while git's real subject
+  // is the NBSP line — an enforcement bypass (Codex review of #3816, verified
+  // against `git stripspace`, which preserves the c2a0 bytes). A Unicode-blank
+  // first line is now returned as the subject and fails the format gate: the
+  // same fail-closed direction git itself takes.
+  const idx = scan.findIndex((l) => !/^[ \t]*$/.test(l));
+  if (idx === -1) return end === -1 ? lines[0] : '';
+
+  // Truncation is only fatal to the line it lands IN. A captured line is complete
+  // exactly when another line follows it, because the capture kept its newline.
+  // So an unterminated body whose subject line is followed by more text is still
+  // measurable; only a subject line that runs to the end of a truncated capture
+  // is not, and that one falls back to the opener — which fails the format gate,
+  // exactly as this whole form did before the fix. Without this, the length gate
+  // measured a PREFIX of the real subject and let an over-long message through
+  // (review of #3802).
+  if (end === -1 && idx >= body.length - 1) return lines[0];
+
+  // git's `cleanup=whitespace` strips whitespace at BOTH ends of the line, not
+  // just leading blanks. Measuring the raw line rejected `feat: <66 x's>` plus
+  // three trailing spaces as 75 chars when git's actual subject is a conforming
+  // 72 — a still-blocked conforming commit, the very defect #3802 reports
+  // (review of #3816). Trailing only, here: leading blank-LINE handling is the
+  // findIndex above, and `<<-` leading-tab stripping already happened.
+  return scan[idx].replace(/[ \t]+$/, '');
+}
+
+module.exports = { isGitSubcommand, tokenize, extractBranchArgument, skipToSubcommand, resolveCommitSubject };

package/hooks/dist/lib/injection-patterns.js

@@ -26,11 +26,29 @@
  */
 
 const INJECTION_PATTERNS = Object.freeze([
-  /ignore\s+(all\s+)?previous\s+instructions/i,
-  /ignore\s+(all\s+)?above\s+instructions/i,
-  /disregard\s+(all\s+)?previous/i,
-  /forget\s+(all\s+)?(your\s+)?instructions/i,
-  /override\s+(system|previous)\s+(prompt|instructions)/i,
+  // #4016: ONE filler-tolerant imperative-override pattern. It REPLACES the
+  // five narrow verb patterns (ignore x2 / disregard / forget / override) that
+  // used to sit here: they tolerated no filler between verb and noun, so a
+  // planted "forget all of your ..." phrasing (measured in the wild) matched
+  // nothing. A single pattern rather than narrow-plus-combined because both
+  // consumers count one finding PER PATTERN toward the severity threshold
+  // (3 = HIGH, blockable under security.injection_blocking): overlapping
+  // patterns made one sentence count twice and pushed a two-phrasing LOW
+  // payload to HIGH (PR #4061 review).
+  //   verbs    ignore|disregard|forget|discard|override. `override` carries
+  //            the old `override system|previous prompt|instructions` family;
+  //            `discard` is the synonym seen in the same planted phrasings.
+  //   fillers  at least ONE of all|of|the|your|my|<qualifier> must sit between
+  //            verb and noun (a lookahead, no repetition). Bare "override
+  //            rules" / "ignore instructions" are ordinary repo prose
+  //            (measured: 6 hits across docs and source) and stay unmatched.
+  //   tails    `disregard (all) previous` with no noun, and bare `forget` +
+  //            `instructions`, are kept verbatim because the old narrow
+  //            patterns accepted them; the superset is pinned by
+  //            tests/injection-patterns-parity.security.test.cjs.
+  //   known FP determined linter-doc prose such as "ignore (the) rules" trips
+  //            a single-pattern LOW advisory; one pattern can never block.
+  /(?:ignore|disregard|forget|discard|override)\s+(?=(?:all|of|the|your|my|system|previous|prior|above|earlier)\s)(?:all\s+)?(?:of\s+)?(?:the\s+|your\s+|my\s+)?(?:(?:system|previous|prior|above|earlier)\s+)?(?:instructions|directives|prompts?|rules)|disregard\s+(?:all\s+)?previous|forget\s+instructions/i,
   /you\s+are\s+now\s+(?:a|an|the)\s+/i,
   /act\s+as\s+(?:a|an|the)\s+(?!plan|phase|wave)/i,
   /pretend\s+(?:you(?:'re| are)\s+|to\s+be\s+)/i,
@@ -42,4 +60,16 @@ const INJECTION_PATTERNS = Object.freeze([
   /<<\s*SYS\s*>>/i,
 ]);
 
-module.exports = { INJECTION_PATTERNS };
+// Short single-line label for a matched pattern, used for both the rendered
+// advisory prose and the typed `findings[].match` field in BOTH consumer
+// hooks. The raw regex source is not user-facing: the #4016 superset pattern
+// is ~280 characters, and gsd-prompt-guard.js echoed it verbatim into its
+// advisory (PR #4061 review nit). Byte-identical to the transform
+// gsd-read-injection-scanner.js carried inline since #3523, hoisted here so
+// one finding renders the same way in both hooks. Both hooks already require
+// this module, so this adds no new staging dependency.
+function describePattern(pattern) {
+  return pattern.source.replace(/\\s\+/g, '-').replace(/[()\\]/g, '').substring(0, 50);
+}
+
+module.exports = { INJECTION_PATTERNS, describePattern };

package/hooks/dist/managed-hooks-registry.cjs

@@ -36,6 +36,7 @@ const MANAGED_HOOKS = [
   'gsd-prompt-guard.js',
   'gsd-read-guard.js',
   'gsd-read-injection-scanner.js',
+  'gsd-secret-read-guard.js',
   'gsd-session-state.sh',
   'gsd-statusline.js',
   'gsd-update-banner.js',

package/hooks/gsd-check-update-worker.js

@@ -156,5 +156,22 @@ const result = {
 };
 
 if (cacheFile) {
-  try { fs.writeFileSync(cacheFile, JSON.stringify(result)); } catch (e) {}
-}
+  // #4091: the cache file is shared per-PACKAGE across every runtime's worker
+  // (#607/#1421), so concurrent statusline/banner readers parse it while this
+  // worker writes it. A direct writeFileSync truncates before writing — a
+  // reader landing mid-write sees a torn/empty record (its JSON.parse catch
+  // swallows it, so the symptom is an intermittently blank update segment).
+  // Publish atomically instead: stage under a unique same-directory temp
+  // (same filesystem, so rename(2) is atomic — readers see the old or the new
+  // record, never a partial one), then renameSync into place. Failure policy
+  // is unchanged (#3582 degrade): any error is swallowed and the temp, if
+  // left behind, is best-effort removed.
+  const tmp = cacheFile + '.tmp-' + process.pid;
+  try {
+    fs.writeFileSync(tmp, JSON.stringify(result));
+    fs.renameSync(tmp, cacheFile);
+  } catch (e) {
+    try {
+      fs.rmSync(tmp, { force: true });
+    } catch (e2) {}
+  }}