Four findings, all suppressed, all real. Three are the same mistake in different places: a state that was never established being reported as a confident answer. - **`readOnDiskEncryption` conflated "no file" with "unreadable file".** Both answered `null`, and the descriptor falls back to the configured write policy on `null` — so a passphrase-configured install reported "File (encrypted)" about a file whose envelope had never parsed, and which `set` was in fact about to refuse rather than overwrite. It now returns a four-state result, and only `absent` falls back to the policy (honestly: the first write really will create it that way). `unreadable` produces `encryptionUnknown` on the descriptor, `plaintext` is omitted entirely so nothing can read a default out of it, and the label, caveat, tone and footer all carry "unreadable" rather than guessing a mode. - **The loose-mode warning overstated exposure for an encrypted file.** "Anyone who can read it can read the secrets in it" is false when the file is ciphertext — a reader gets the bytes and still needs the passphrase. Both the caveat and the footer tooltip now branch on encryption: the passphrase becomes the only protection, which is the real consequence. Overstating it is not harmless, because a warning that cries wolf is discounted on the occasion it is literally true. - **The keychain hand-off could invert its own keychain-wins rule.** `SecretStore.get` answers `null` both for a missing entry and for a keychain it could not read, and the migration *writes* on `null` — so a transient read failure would overwrite a newer keychain value with the older file copy. Added an optional `getStrict` (throws instead of swallowing) implemented by `KeyringSecretStore`, with `secretStoreGetStrict` falling back to `get` for stores whose reads cannot fail. A throw now aborts the hand-off with the file left in place, so the next run retries. Writing the tests turned up one more, in code the review had passed: `parseOwner` recorded a garbled pid as `-1`, and `process.kill(-1, 0)` is a *wildcard* asking about every process this user can signal — it answers "alive" almost always, which would have made a lock with a corrupt stamp permanently unstealable. Only a positive pid is usable now; anything else is treated as no pid at all and the mtime decides. Tests: the four envelope states kept distinct; the descriptor refusing to guess, with the genuine no-file case as the control; strict-read abort without a write and with the file preserved, plus a store whose `get` and `getStrict` disagree so the test proves which one the migration consults; encryption-aware wording asserted in both directions in the caveat and the band; three unusable owner stamps and a wildcard pid; and the descriptor shapes that must now be rejected — neither half of the encryption question answered, or both. Full `npm run ci` green — 5,750 tests under the coverage gate. Signed-off-by: cliffhall <cliff@futurescale.com>
207 lines
9.3 KiB
TypeScript
207 lines
9.3 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;
|
|
/**
|
|
* Set when the secrets file exists and its mode could not be read at all
|
|
* — `EACCES` on the containing directory, or a filesystem with no POSIX
|
|
* modes. Carries the errno so the message can say why.
|
|
*
|
|
* Distinct from {@link looseMode}, and the distinction matters: that one
|
|
* says "we looked and it is wrong", this one says "we could not look".
|
|
* Collapsing the second into silence is what let the footer keep stating
|
|
* mode 0600 as fact having verified nothing.
|
|
*/
|
|
permissionsUnknown?: string;
|
|
/**
|
|
* Set when the secrets file exists but its envelope could not be read —
|
|
* corrupt JSON, or a format written by a newer Inspector. Carries the
|
|
* reason.
|
|
*
|
|
* Mutually exclusive with a meaningful {@link plaintext}: the whole point
|
|
* is that the encryption state was never established, so neither "File
|
|
* (encrypted)" nor "File (unencrypted)" may be claimed. `set` will refuse
|
|
* such a file rather than overwrite it, so this is also a live warning
|
|
* about writes, not only a description.
|
|
*/
|
|
encryptionUnknown?: string;
|
|
/**
|
|
* 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":
|
|
if (info.encryptionUnknown !== undefined) return "File (unreadable)";
|
|
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";
|
|
// Unverified is not the same as fine. The quiet tone here would read as a
|
|
// confirmation we never made.
|
|
if (info.permissionsUnknown !== undefined) return "warn";
|
|
// A file we cannot read is one we cannot write either — a warning about
|
|
// the next save, not just about the past.
|
|
if (info.encryptionUnknown !== undefined) return "warn";
|
|
return "neutral";
|
|
}
|
|
|
|
/**
|
|
* One sentence of consequence, or undefined when there is none worth
|
|
* saying. Consequence, not mechanism: "lost on exit" 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 on exit.";
|
|
}
|
|
// 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");
|
|
// The consequence differs by encryption, and overstating it is its own
|
|
// kind of wrong: a reader of an *encrypted* file gets ciphertext, not
|
|
// secrets. Saying otherwise trains people to discount the warning on the
|
|
// occasion it is literally true.
|
|
return info.plaintext === false
|
|
? `The secrets file is mode ${mode}, not 0600, and could not be tightened — others can copy it, and the passphrase is then the only thing protecting its contents.`
|
|
: `The secrets file is mode ${mode}, not 0600, and could not be tightened — anyone who can read it can read the secrets in it.`;
|
|
}
|
|
// Ordered with the permission problems, above encryption, for the same
|
|
// reason: not knowing whether others can read the file is a question about
|
|
// exposure, and it should not be answered by a reassuring silence.
|
|
if (info.permissionsUnknown !== undefined) {
|
|
return `The secrets file's permissions could not be checked (${info.permissionsUnknown}), so it is not known whether others can read it.`;
|
|
}
|
|
// An unreadable envelope outranks the encryption caveats below, which all
|
|
// presuppose we know which mode the file is in.
|
|
if (info.encryptionUnknown !== undefined) {
|
|
return `The secrets file could not be read (${info.encryptionUnknown}). Saving a secret will fail rather than overwrite 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(" ");
|
|
}
|