litmus-cli 1.4.22 → 1.4.25

package/dist/lib/workspace-token.d.ts

@@ -0,0 +1,69 @@
+/**
+ * Where `litmus push` gets its assessment token (ENG-2064).
+ *
+ * The command has two callers and they hold the credential differently:
+ *
+ *   * ON A LAPTOP the candidate types it, `litmus push <token>`, copied from their
+ *     assessment page. That is unchanged and stays the first branch here, so an
+ *     explicit argument always wins.
+ *   * INSIDE A CODESPACES v2 WORKSPACE nobody should type anything. The container
+ *     was created for exactly one candidate, so the host already knows who they
+ *     are and injects their own token at container start, the same way it injects
+ *     the AI gateway pre-auth. See litmus-firstboot 3c in
+ *     `infra/codespaces-v2-image/entrypoint/litmus-firstboot.sh` and hostd's
+ *     `sanitize_workspace_env`.
+ *
+ * WHY AN ENV VAR AND NOT A FILE. The container's one persistent surface is the
+ * candidate home, and everything in it rides the submission zip and the R2
+ * durability tar. A bearer token must be at rest in neither, which is exactly why
+ * `hostd._stage_litmus_config` declines to put one in `.litmus/config.json`. The
+ * env is staged per boot into a root-owned file that firstboot CONSUMES, so
+ * nothing survives the boot on disk.
+ *
+ * The name is NOT a routing input and never has been (ENG-1025): it carries the
+ * credential only. `LITMUS_API_URL` still decides which deployment we talk to, and
+ * the workspace injects that separately.
+ */
+/** The env name the workspace injects the candidate's own token under. */
+export declare const WORKSPACE_TOKEN_ENV = "LITMUS_ASSESSMENT_TOKEN";
+/**
+ * Where the Codespaces v2 image installs this CLI.
+ *
+ * MUST match `DEST` in `infra/codespaces-v2-image/scripts/install-litmus-cli.sh`;
+ * `backend/tests/test_workspace_cli_install.py` holds the two together.
+ */
+export declare const WORKSPACE_INSTALL_PREFIX = "/opt/litmus/cli/";
+/**
+ * The token to authenticate with, or `null` when we have none.
+ *
+ * `null` rather than a throw so the caller owns the wording: what to tell a
+ * candidate depends on whether they are sitting in a terminal we pre-authed
+ * (something is wrong with their container) or on their own machine (they simply
+ * left the argument off).
+ */
+export declare function resolveAssessmentToken(argToken: string | undefined, env?: NodeJS.ProcessEnv): string | null;
+/**
+ * Is this the copy of the CLI baked into a Litmus workspace image?
+ *
+ * Read from our OWN module path rather than from an environment variable, and
+ * that choice is load-bearing. sshd builds a session environment from scratch, so
+ * a marker baked as a Docker `ENV` is simply absent in the candidate's shell
+ * unless it is also on the sshd allowlist, and a marker we inject alongside the
+ * token disappears in precisely the case this predicate exists to describe: the
+ * injection did not happen. The install prefix is a property of the artifact, is
+ * root-owned on a read-only rootfs, and is true whether or not staging worked.
+ *
+ * COMPARED ON THE URL's OWN PATHNAME, never on a host filesystem path, and that
+ * is the cross-platform rule AGENTS.md states for anything in `cli/src` reasoning
+ * about a path belonging to some OTHER platform. `WORKSPACE_INSTALL_PREFIX` is a
+ * LINUX container path; `fileURLToPath` renders for the HOST, so on Windows it
+ * answers `\opt\litmus\cli\...` and the prefix can never match. A file URL's
+ * pathname is always slash-separated by definition, so this is the one comparison
+ * that is correct on every host — which matters because the Windows CLI gate runs
+ * these tests and their expectations are literal paths.
+ *
+ * Used only to choose which sentence a candidate reads. Nothing security-relevant
+ * hangs off it.
+ */
+export declare function isWorkspaceInstall(moduleUrl: string): boolean;
+//# sourceMappingURL=workspace-token.d.ts.map

package/dist/lib/workspace-token.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"workspace-token.d.ts","sourceRoot":"","sources":["../../src/lib/workspace-token.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;GAyBG;AAEH,0EAA0E;AAC1E,eAAO,MAAM,mBAAmB,4BAA4B,CAAA;AAE5D;;;;;GAKG;AACH,eAAO,MAAM,wBAAwB,qBAAqB,CAAA;AAE1D;;;;;;;GAOG;AACH,wBAAgB,sBAAsB,CACpC,QAAQ,EAAE,MAAM,GAAG,SAAS,EAC5B,GAAG,GAAE,MAAM,CAAC,UAAwB,GACnC,MAAM,GAAG,IAAI,CAMf;AAED;;;;;;;;;;;;;;;;;;;;;;GAsBG;AACH,wBAAgB,kBAAkB,CAAC,SAAS,EAAE,MAAM,GAAG,OAAO,CAc7D"}

package/dist/lib/workspace-token.js

@@ -0,0 +1,93 @@
+/**
+ * Where `litmus push` gets its assessment token (ENG-2064).
+ *
+ * The command has two callers and they hold the credential differently:
+ *
+ *   * ON A LAPTOP the candidate types it, `litmus push <token>`, copied from their
+ *     assessment page. That is unchanged and stays the first branch here, so an
+ *     explicit argument always wins.
+ *   * INSIDE A CODESPACES v2 WORKSPACE nobody should type anything. The container
+ *     was created for exactly one candidate, so the host already knows who they
+ *     are and injects their own token at container start, the same way it injects
+ *     the AI gateway pre-auth. See litmus-firstboot 3c in
+ *     `infra/codespaces-v2-image/entrypoint/litmus-firstboot.sh` and hostd's
+ *     `sanitize_workspace_env`.
+ *
+ * WHY AN ENV VAR AND NOT A FILE. The container's one persistent surface is the
+ * candidate home, and everything in it rides the submission zip and the R2
+ * durability tar. A bearer token must be at rest in neither, which is exactly why
+ * `hostd._stage_litmus_config` declines to put one in `.litmus/config.json`. The
+ * env is staged per boot into a root-owned file that firstboot CONSUMES, so
+ * nothing survives the boot on disk.
+ *
+ * The name is NOT a routing input and never has been (ENG-1025): it carries the
+ * credential only. `LITMUS_API_URL` still decides which deployment we talk to, and
+ * the workspace injects that separately.
+ */
+/** The env name the workspace injects the candidate's own token under. */
+export const WORKSPACE_TOKEN_ENV = "LITMUS_ASSESSMENT_TOKEN";
+/**
+ * Where the Codespaces v2 image installs this CLI.
+ *
+ * MUST match `DEST` in `infra/codespaces-v2-image/scripts/install-litmus-cli.sh`;
+ * `backend/tests/test_workspace_cli_install.py` holds the two together.
+ */
+export const WORKSPACE_INSTALL_PREFIX = "/opt/litmus/cli/";
+/**
+ * The token to authenticate with, or `null` when we have none.
+ *
+ * `null` rather than a throw so the caller owns the wording: what to tell a
+ * candidate depends on whether they are sitting in a terminal we pre-authed
+ * (something is wrong with their container) or on their own machine (they simply
+ * left the argument off).
+ */
+export function resolveAssessmentToken(argToken, env = process.env) {
+    const explicit = argToken?.trim();
+    if (explicit)
+        return explicit;
+    const injected = env[WORKSPACE_TOKEN_ENV]?.trim();
+    if (injected)
+        return injected;
+    return null;
+}
+/**
+ * Is this the copy of the CLI baked into a Litmus workspace image?
+ *
+ * Read from our OWN module path rather than from an environment variable, and
+ * that choice is load-bearing. sshd builds a session environment from scratch, so
+ * a marker baked as a Docker `ENV` is simply absent in the candidate's shell
+ * unless it is also on the sshd allowlist, and a marker we inject alongside the
+ * token disappears in precisely the case this predicate exists to describe: the
+ * injection did not happen. The install prefix is a property of the artifact, is
+ * root-owned on a read-only rootfs, and is true whether or not staging worked.
+ *
+ * COMPARED ON THE URL's OWN PATHNAME, never on a host filesystem path, and that
+ * is the cross-platform rule AGENTS.md states for anything in `cli/src` reasoning
+ * about a path belonging to some OTHER platform. `WORKSPACE_INSTALL_PREFIX` is a
+ * LINUX container path; `fileURLToPath` renders for the HOST, so on Windows it
+ * answers `\opt\litmus\cli\...` and the prefix can never match. A file URL's
+ * pathname is always slash-separated by definition, so this is the one comparison
+ * that is correct on every host — which matters because the Windows CLI gate runs
+ * these tests and their expectations are literal paths.
+ *
+ * Used only to choose which sentence a candidate reads. Nothing security-relevant
+ * hangs off it.
+ */
+export function isWorkspaceInstall(moduleUrl) {
+    let pathname;
+    try {
+        const url = new URL(moduleUrl);
+        // A non-file URL is not an install location. Checked rather than assumed so an
+        // `https:` module URL cannot match by having a same-looking path.
+        if (url.protocol !== "file:")
+            return false;
+        pathname = decodeURIComponent(url.pathname);
+    }
+    catch {
+        // Only decides which sentence a candidate reads, so an exotic or malformed
+        // module URL must degrade to the laptop wording rather than crash the command.
+        return false;
+    }
+    return pathname.startsWith(WORKSPACE_INSTALL_PREFIX);
+}
+//# sourceMappingURL=workspace-token.js.map

package/dist/lib/workspace-token.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"workspace-token.js","sourceRoot":"","sources":["../../src/lib/workspace-token.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;GAyBG;AAEH,0EAA0E;AAC1E,MAAM,CAAC,MAAM,mBAAmB,GAAG,yBAAyB,CAAA;AAE5D;;;;;GAKG;AACH,MAAM,CAAC,MAAM,wBAAwB,GAAG,kBAAkB,CAAA;AAE1D;;;;;;;GAOG;AACH,MAAM,UAAU,sBAAsB,CACpC,QAA4B,EAC5B,MAAyB,OAAO,CAAC,GAAG;IAEpC,MAAM,QAAQ,GAAG,QAAQ,EAAE,IAAI,EAAE,CAAA;IACjC,IAAI,QAAQ;QAAE,OAAO,QAAQ,CAAA;IAC7B,MAAM,QAAQ,GAAG,GAAG,CAAC,mBAAmB,CAAC,EAAE,IAAI,EAAE,CAAA;IACjD,IAAI,QAAQ;QAAE,OAAO,QAAQ,CAAA;IAC7B,OAAO,IAAI,CAAA;AACb,CAAC;AAED;;;;;;;;;;;;;;;;;;;;;;GAsBG;AACH,MAAM,UAAU,kBAAkB,CAAC,SAAiB;IAClD,IAAI,QAAgB,CAAA;IACpB,IAAI,CAAC;QACH,MAAM,GAAG,GAAG,IAAI,GAAG,CAAC,SAAS,CAAC,CAAA;QAC9B,+EAA+E;QAC/E,kEAAkE;QAClE,IAAI,GAAG,CAAC,QAAQ,KAAK,OAAO;YAAE,OAAO,KAAK,CAAA;QAC1C,QAAQ,GAAG,kBAAkB,CAAC,GAAG,CAAC,QAAQ,CAAC,CAAA;IAC7C,CAAC;IAAC,MAAM,CAAC;QACP,2EAA2E;QAC3E,+EAA+E;QAC/E,OAAO,KAAK,CAAA;IACd,CAAC;IACD,OAAO,QAAQ,CAAC,UAAU,CAAC,wBAAwB,CAAC,CAAA;AACtD,CAAC"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "litmus-cli",
-  "version": "1.4.22",
+  "version": "1.4.25",
   "description": "CLI tool for Litmus engineering assessments",
   "license": "MIT",
   "author": "elenazhao",