inspector/core/auth/secret-storage-info.ts
cliffhall b143dd6cbd fix(auth): address Copilot review round 3 on the secret-store PR
Nine findings (six inline, three suppressed), all taken. Two were serious.

**The memory fallback made the migrations destructive.** Both migrations —
mcp.json in the remote server, client.json in `node-persistence` — lift a
plaintext secret off disk, write it to the secret store, and then delete it
from the file. That trade is safe only while the store is at least as
durable as the disk, which held by construction while `InMemorySecretStore`
was a test double. Making it a production fallback broke it: on an
unmounted container a plain `GET /api/servers` would have moved a user's
existing secrets into RAM and lost them at exit — destroying data on a
read.

`SecretStore` gains an optional `isDurable()`, absent meaning durable, and
both migrations withhold the disk delete when it answers false (the value
is still loaded, so the session behaves normally). The production fallback
is now a named `SessionSecretStore` rather than the bare
`InMemorySecretStore`, so the suite's many doubles keep standing in for a
*working keychain* — which is what they are there to be — and only code
that deliberately chooses RAM in production says so.

**Round 2's per-call descriptor never reached anyone.** Both web servers
resolved it once at startup and baked it into `initialConfig`, which
`/api/config` serves unchanged — so the freshness fix was inert for its
only consumer. The route now takes a `secretStorageResolver` and calls it
per request.

The lock needed three more fixes, and they compound:

- **Release removed whatever directory was at the path.** A holder whose
  work outran the stale threshold would delete the *next* owner's lock,
  letting a third writer into a section two processes believed they held.
  Ownership is now stamped with a random token and release only removes a
  lock still carrying it.
- **The timeout fell through to an unlocked write** — under contention,
  the one moment another writer is provably active. It now throws
  `SecretFileLockTimeoutError`, which `set` is allowed to do.
- **The first write of every process bypassed the lock**, because the
  secrets directory does not exist yet and `mkdir` failed ENOENT. The
  parent is created first. First writes are exactly when two processes are
  most likely to start together.

Fixing the timeout exposed a fourth: with stale (10s) below timeout, a
waiter stole from a holder that was merely *slow* rather than dead —
reinstating the lost update. A holder now heartbeats its lock, so
"stale" means the holder is gone, and the timeout is what a live-but-slow
holder produces. Lock timings are injectable so the tests can exercise
contention, staleness, and timeout without spending the real intervals.

Also: the loose-permission state is carried into `SecretStorageInfo` as
`looseMode` and rendered as the caveat (it outranks the encryption caveat —
a file others can read is a live exposure, while "unencrypted" is a
property of a file only its owner can open), rather than living in a
startup log the browser cannot see; and `usableSecretStorage` validates
`pendingEncryption` and `looseMode` as the optional booleans/numbers they
are (`pendingEncryption: "false"` is truthy and would have printed advice
that is the opposite of the truth) and rejects file-only fields on a
keychain or memory descriptor.

Tests: both migrations against a session store with a durable control
alongside, so the guard is visibly the difference; `/api/config` serving a
changing resolver and falling back without one; lock ownership after a
steal, the timeout under a live holder, no-steal from a slow holder, and a
locked first write; `looseMode` through the descriptor, the caveat
ordering, and the tone; and five more rejected payload shapes. Full
`npm run ci` green — 5,704 tests under the coverage gate.

Signed-off-by: cliffhall <cliff@futurescale.com>
2026-08-22 13:19:56 -04:00

160 lines
6.7 KiB
TypeScript

/**
* The description of *where a typed secret ends up* — the one fact this
* whole subsystem exists to make unmissable (#1950).
*
* Pure data plus its presentation helpers, deliberately kept out of
* `core/auth/node/` so the browser can import it. The Node side resolves
* the active store (`core/auth/node/secret-store-selection.ts`) and
* produces one of these; it then travels three ways, and all three read
* the same object so they cannot disagree:
*
* 1. the startup banner the launcher prints,
* 2. `GET /api/config` → the web UI's settings-modal footers,
* 3. the `SecretStore` doc comment's contract, in prose.
*
* A store's *kind* answers "where", `plaintext` answers "readable by
* anyone who can read the file", and `durable` answers "will it still be
* there next run". Those are three separate questions and a user asking
* one of them is rarely helped by the answer to another, so none is
* folded into the others.
*/
/** Which backend is holding secrets this session. */
export type SecretStoreKind = "keyring" | "file" | "memory";
/**
* Why the active store is the active store. `configured` means the user
* named it via `MCP_INSPECTOR_SECRET_STORE`; `default` means the keychain
* was reachable and we used it; `fallback` means the keychain was *not*
* reachable and we picked something that works instead — the case that
* earns a loud banner, because it is the one where the answer to "where
* did my secret go" changed without the user asking for it.
*/
export type SecretStoreReason = "configured" | "default" | "fallback";
export interface SecretStorageInfo {
kind: SecretStoreKind;
reason: SecretStoreReason;
/**
* Absolute path of the secrets file, for `kind: "file"` only. Shown in
* the UI and the banner: a file-backed store whose location is a
* mystery is barely better than no answer at all.
*/
path?: string;
/**
* True when the secrets file is *currently* in the clear. Read off the
* file's own envelope rather than off whether a passphrase is
* configured, because those two disagree for a whole session: adding
* `MCP_INSPECTOR_SECRET_KEY` to an install that already has a plaintext
* file makes the next write encrypt, while the existing bytes stay
* readable until then. Reporting the intent would tell that user their
* secrets were encrypted while they were not.
*
* Always false for the other kinds — a keychain is opaque to us and RAM
* is not "at rest" in the sense this flag is about.
*/
plaintext?: boolean;
/**
* True in exactly the transitional state above: `plaintext` is still
* true, but a passphrase is set and the next write will encrypt. It
* changes the *advice* rather than the verdict — "set a passphrase" is
* the wrong thing to tell someone who already has, so the caveat says
* what will actually clear the condition.
*/
pendingEncryption?: boolean;
/**
* Octal mode of the secrets file when it is **not** `0600` and could not
* be tightened — a file owned by another user, or on a read-only mount.
*
* Carried into the descriptor rather than left in a startup log line
* because the caveat below states the mode as fact, at the point where a
* user types a secret. On such a box that statement was simply untrue,
* and the browser had no way to know.
*/
looseMode?: number;
/**
* True when secrets outlive the process. False only for `memory`, and
* it is the *promise* being made rather than an implementation detail:
* an in-memory store is honest precisely because it never claims
* durability it cannot deliver in a container's writable layer.
*/
durable: boolean;
/**
* Why the keychain was unreachable, when `reason === "fallback"`. Free
* text from the underlying loader/binding — surfaced rather than
* summarized, because the three realistic causes (missing libsecret, no
* platform binary, a packaging mismatch) need different fixes and only
* the raw message distinguishes them.
*/
detail?: string;
}
/** Short label naming the store — the footer's primary text. */
export function secretStorageLabel(info: SecretStorageInfo): string {
switch (info.kind) {
case "keyring":
return "OS keychain";
case "file":
return info.plaintext ? "File (unencrypted)" : "File (encrypted)";
case "memory":
return "Memory (this session only)";
}
}
/**
* How loudly to say it. `warn` is reserved for the two states a user
* would want to know about before typing a secret — it is on disk in the
* clear, or it is about to be lost on exit — so that the ordinary
* keychain and encrypted-file cases stay quiet and the warning keeps its
* meaning.
*/
export type SecretStorageTone = "neutral" | "warn";
export function secretStorageTone(info: SecretStorageInfo): SecretStorageTone {
if (info.kind === "memory") return "warn";
if (info.plaintext) return "warn";
// An encrypted file that anyone can read is still worth flagging: the
// passphrase is the only thing standing between a reader and the values.
if (info.looseMode !== undefined) return "warn";
return "neutral";
}
/**
* One sentence of consequence, or undefined when there is none worth
* saying. Consequence, not mechanism: "will be lost when the Inspector
* exits" is what a user can act on; "uses an in-memory Map" is not.
*/
export function secretStorageCaveat(
info: SecretStorageInfo,
): string | undefined {
if (info.kind === "memory") {
return "Secrets are not written anywhere and are lost when the Inspector exits.";
}
// The permission problem outranks the encryption one when both hold: a
// file other users can read is a live exposure, while "unencrypted" is a
// property of a file only its owner can open.
if (info.looseMode !== undefined) {
const mode = info.looseMode.toString(8).padStart(4, "0");
return `The secrets file is mode ${mode}, not 0600, and could not be tightened — anyone who can read it can read the secrets in it.`;
}
if (info.plaintext) {
return info.pendingEncryption
? "Existing secrets in this file are still unencrypted (file mode 0600). They are re-encrypted the next time a secret is saved."
: "Secrets are stored unencrypted (file mode 0600). Set MCP_INSPECTOR_SECRET_KEY to encrypt them.";
}
return undefined;
}
/**
* The full sentence, for the startup banner and any single-line surface.
* Built from the same three helpers the UI uses so the terminal and the
* browser cannot drift into describing the same store differently.
*/
export function secretStorageSummary(info: SecretStorageInfo): string {
const parts = [secretStorageLabel(info)];
if (info.path) parts.push(`at ${info.path}`);
if (info.reason === "fallback") {
parts.push("— fell back from the OS keychain");
}
return parts.join(" ");
}