@skrr-ai/cli 0.1.93 → 0.1.95

package/dist/node_modules/@skrr-ai/auth-core/dist/cjs/firstPartyHarnessReleaseKeys.d.ts

@@ -0,0 +1,82 @@
+/**
+ * WL-6.8 — ed25519 public keys that vouch for a **first-party harness binary**.
+ *
+ * ── Why this is not `daemon/src/release-keys.ts` ───────────────────────────
+ *
+ * `verifyHarnessProvenance` originally defaulted to the daemon's own
+ * self-update keys. That is convenient and wrong. Those two keys answer
+ * different questions and protect different things:
+ *
+ *   `OVERSKY_RELEASE_PUBLIC_KEYS`  — "may this binary REPLACE the daemon?"
+ *   `FIRST_PARTY_HARNESS_RELEASE_PUBLIC_KEYS` — "may this binary receive a
+ *                                              platform credential?"
+ *
+ * Sharing one key means a compromise of the harness signing identity is also a
+ * forged-daemon-self-update primitive: an attacker who can sign a harness can
+ * sign a manifest that the daemon installs over itself. That is a strictly
+ * larger blast radius than the harness key needs to carry, and it is
+ * unnecessary — the two artifacts have different release cadences and
+ * different publishers, so they were always going to want independent
+ * rotation.
+ *
+ * Separating them costs one more secret to provision and removes an
+ * escalation path. That trade is not close.
+ *
+ * ── Fail-closed, and in the direction that matters ─────────────────────────
+ *
+ * EMPTY means provenance can never be established. Until 2026-08-11 that also
+ * meant the first-party harness was held at Tier 2 on a scoped gateway token; that
+ * floor has since been removed, and it is DECLARED Tier 1, so an empty list no
+ * longer withholds the credential privilege from it. What an empty list still
+ * costs is the ability to say WHICH BYTES held the credential — the verdict
+ * becomes `unverifiable`, and the record is silent about the binary on disk.
+ *
+ * The fail-closed direction below still governs every OTHER
+ * OverSky-distributed harness, and remains the correct posture for this one if
+ * the floor is ever restored.
+ *
+ * Note this is the OPPOSITE posture to the daemon's own `../release-keys.ts`
+ * (same basename, different module), deliberately. There,
+ * an empty list disables verification and the updater proceeds, because a fleet
+ * that cannot update is its own outage. Here, an empty list withholds a
+ * privilege, because absence of evidence must never grant one. Getting these
+ * two backwards would mean provisioning a key *reduces* what the daemon trusts.
+ *
+ * ── Provisioning ──────────────────────────────────────────────────────────
+ *
+ *   1. Mint:   node scripts/first-party-harness/generate-signing-key.mjs   (in the fork)
+ *   2. Store the PRIVATE half as the GH Actions secret
+ *      `FIRST_PARTY_HARNESS_ENV.signingKey.name` (the only name the publish
+ *      workflow reads) + AWS Secrets Manager. It must never be committed and
+ *      never leave CI.
+ *   3. Paste the PUBLIC half below, newest first.
+ *   4. Ship a daemon build carrying it BEFORE the first signed harness
+ *      release, so the fleet can verify what it is about to be handed.
+ *
+ * Rotation is the same shape as the daemon's: add the next key ABOVE the
+ * current one, ship that build, then start dual-signing. Verification accepts
+ * any pinned key, so an overlap window has no gap.
+ */
+import type { ReleaseKey } from './releaseKeys.js';
+export type { ReleaseKey };
+/**
+ * Pinned first-party harness signing public keys, newest first.
+ *
+ * Provisioned 2026-08-07 (WL-6.8). The private half lives in the GitHub secret
+ * named by `FIRST_PARTY_HARNESS_ENV.signingKey` and in AWS Secrets Manager — a
+ * HARNESS key, deliberately a different trust domain from the daemon
+ * self-update key in `../release-keys.ts`.
+ *
+ * ── Two literals that must NOT follow a rename (contract §6) ────────────────
+ * The `keyId` below and the AWS secret path `oversky/sky-code/signing-key` are
+ * historical identifiers, not the product name. A key id is inside every
+ * signature ever issued and every provenance sidecar ever written, so changing
+ * it would make every existing release unverifiable; the secret is stateful
+ * infrastructure. Both move only at the next key ROTATION.
+ *
+ * ORDER OF OPERATIONS, and it only works one way round: this pinned build must
+ * SHIP before any harness release is signed. Backwards, the fleet receives an
+ * artifact it cannot verify and every daemon reports `invalid-signature` —
+ * which from the outside is indistinguishable from a real attack.
+ */
+export declare const FIRST_PARTY_HARNESS_RELEASE_PUBLIC_KEYS: ReleaseKey[];

package/dist/node_modules/@skrr-ai/auth-core/dist/cjs/firstPartyHarnessReleaseKeys.js

@@ -0,0 +1,105 @@
+"use strict";
+/**
+ * WL-6.8 — ed25519 public keys that vouch for a **first-party harness binary**.
+ *
+ * ── Why this is not `daemon/src/release-keys.ts` ───────────────────────────
+ *
+ * `verifyHarnessProvenance` originally defaulted to the daemon's own
+ * self-update keys. That is convenient and wrong. Those two keys answer
+ * different questions and protect different things:
+ *
+ *   `OVERSKY_RELEASE_PUBLIC_KEYS`  — "may this binary REPLACE the daemon?"
+ *   `FIRST_PARTY_HARNESS_RELEASE_PUBLIC_KEYS` — "may this binary receive a
+ *                                              platform credential?"
+ *
+ * Sharing one key means a compromise of the harness signing identity is also a
+ * forged-daemon-self-update primitive: an attacker who can sign a harness can
+ * sign a manifest that the daemon installs over itself. That is a strictly
+ * larger blast radius than the harness key needs to carry, and it is
+ * unnecessary — the two artifacts have different release cadences and
+ * different publishers, so they were always going to want independent
+ * rotation.
+ *
+ * Separating them costs one more secret to provision and removes an
+ * escalation path. That trade is not close.
+ *
+ * ── Fail-closed, and in the direction that matters ─────────────────────────
+ *
+ * EMPTY means provenance can never be established. Until 2026-08-11 that also
+ * meant the first-party harness was held at Tier 2 on a scoped gateway token; that
+ * floor has since been removed, and it is DECLARED Tier 1, so an empty list no
+ * longer withholds the credential privilege from it. What an empty list still
+ * costs is the ability to say WHICH BYTES held the credential — the verdict
+ * becomes `unverifiable`, and the record is silent about the binary on disk.
+ *
+ * The fail-closed direction below still governs every OTHER
+ * OverSky-distributed harness, and remains the correct posture for this one if
+ * the floor is ever restored.
+ *
+ * Note this is the OPPOSITE posture to the daemon's own `../release-keys.ts`
+ * (same basename, different module), deliberately. There,
+ * an empty list disables verification and the updater proceeds, because a fleet
+ * that cannot update is its own outage. Here, an empty list withholds a
+ * privilege, because absence of evidence must never grant one. Getting these
+ * two backwards would mean provisioning a key *reduces* what the daemon trusts.
+ *
+ * ── Provisioning ──────────────────────────────────────────────────────────
+ *
+ *   1. Mint:   node scripts/first-party-harness/generate-signing-key.mjs   (in the fork)
+ *   2. Store the PRIVATE half as the GH Actions secret
+ *      `FIRST_PARTY_HARNESS_ENV.signingKey.name` (the only name the publish
+ *      workflow reads) + AWS Secrets Manager. It must never be committed and
+ *      never leave CI.
+ *   3. Paste the PUBLIC half below, newest first.
+ *   4. Ship a daemon build carrying it BEFORE the first signed harness
+ *      release, so the fleet can verify what it is about to be handed.
+ *
+ * Rotation is the same shape as the daemon's: add the next key ABOVE the
+ * current one, ship that build, then start dual-signing. Verification accepts
+ * any pinned key, so an overlap window has no gap.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.FIRST_PARTY_HARNESS_RELEASE_PUBLIC_KEYS = void 0;
+/**
+ * Pinned first-party harness signing public keys, newest first.
+ *
+ * Provisioned 2026-08-07 (WL-6.8). The private half lives in the GitHub secret
+ * named by `FIRST_PARTY_HARNESS_ENV.signingKey` and in AWS Secrets Manager — a
+ * HARNESS key, deliberately a different trust domain from the daemon
+ * self-update key in `../release-keys.ts`.
+ *
+ * ── Two literals that must NOT follow a rename (contract §6) ────────────────
+ * The `keyId` below and the AWS secret path `oversky/sky-code/signing-key` are
+ * historical identifiers, not the product name. A key id is inside every
+ * signature ever issued and every provenance sidecar ever written, so changing
+ * it would make every existing release unverifiable; the secret is stateful
+ * infrastructure. Both move only at the next key ROTATION.
+ *
+ * ORDER OF OPERATIONS, and it only works one way round: this pinned build must
+ * SHIP before any harness release is signed. Backwards, the fleet receives an
+ * artifact it cannot verify and every daemon reports `invalid-signature` —
+ * which from the outside is indistinguishable from a real attack.
+ */
+exports.FIRST_PARTY_HARNESS_RELEASE_PUBLIC_KEYS = [
+    // ── NEXT key goes ABOVE this line during a rotation (newest first). ──
+    {
+        // Literal on purpose: a key id is inside every signature issued (contract §6).
+        keyId: 'sky-code-2026-08',
+        publicKeySpkiB64: 'MCowBQYDK2VwAyEAO/5glF6bICuz5MGYgG1PJaDEgXJZkUuv2cLzguVZCvY=',
+    },
+];
+/*
+ * Dev/test escape hatch: an absolute path to a JSON file holding
+ * `[{ keyId, publicKeySpkiB64 }]`, named by `FIRST_PARTY_HARNESS_ENV.devKeys` and
+ * read in `./provenance.ts` with `readFirstPartyHarnessEnv(env, 'devKeys')` — its
+ * brand-neutral name, the only one read.
+ *
+ * Exists so a developer can build, sign, and verify a local harness end to end
+ * without minting a production key — the alternative is that the whole trust
+ * chain is only ever exercised in CI, which is how it rots.
+ *
+ * Deliberately NOT a way to weaken production: it can only ADD keys a local
+ * operator explicitly pointed at, it is read from an absolute path (a relative
+ * one would be attacker-influenced via cwd), and a build that ships with an
+ * empty pinned list still refuses to elevate without it.
+ */

package/dist/node_modules/@skrr-ai/auth-core/dist/cjs/firstPartyHarnessUpdater.d.ts

@@ -0,0 +1,110 @@
+import { type FirstPartyHarnessChannel } from './firstPartyHarnessChannels.js';
+import { type DaemonVersionManifest, type PlatformArtifact, type ReleaseKey } from './releaseManifest.js';
+export { FIRST_PARTY_HARNESS_RELEASE_PUBLIC_KEYS } from './firstPartyHarnessReleaseKeys.js';
+export { firstPartyHarnessFeedBase, firstPartyHarnessFeedCandidates, } from './firstPartyHarnessChannels.js';
+export { firstPartyHarnessManifestFile } from './firstPartyHarness.js';
+export type { ReleaseKey } from './releaseManifest.js';
+export declare const PREVIOUS_SUFFIX = ".previous";
+export declare const PROVENANCE_SUFFIX = ".oversky-provenance.json";
+export declare const MAX_ARTIFACT_BYTES: number;
+export type InstallFailureCode = 'unsupported-platform' | 'feed-unreachable' | 'manifest-malformed' | 'manifest-unverified' | 'artifact-missing' | 'artifact-unverified' | 'download-failed' | 'hash-mismatch' | 'too-large' | 'install-failed' | 'no-pinned-keys' | 'downgrade-refused' | 'version-invalid' | 'lock-busy' | 'minimum-version' | 'policy-rejected';
+export interface InstallResult {
+    ok: boolean;
+    version?: string;
+    platform?: string;
+    binaryPath?: string;
+    replaced?: boolean;
+    changed?: boolean;
+    reason?: string;
+    code?: InstallFailureCode;
+    error?: string;
+}
+export interface InstallOptions {
+    env?: NodeJS.ProcessEnv;
+    keys?: readonly ReleaseKey[];
+    fetchImpl?: typeof fetch;
+    platform?: NodeJS.Platform;
+    arch?: string;
+    onProgress?: (message: string) => void;
+    version?: string;
+    allowDowngrade?: boolean;
+    signal?: AbortSignal;
+    manifestTimeoutMs?: number;
+    autonomous?: boolean;
+    cohortSubject?: string;
+    contracts?: Record<string, number>;
+    now?: Date;
+}
+export interface HarnessProvenanceRecord {
+    version: string;
+    platform: string;
+    sha256: string;
+    url: string;
+    sig: string;
+    sigs?: PlatformArtifact['sigs'];
+    keyId?: string;
+}
+export interface FirstPartyHarnessUpdateState {
+    operation: 'install' | 'rollback';
+    status: 'running' | 'succeeded' | 'failed';
+    attemptedAt: number;
+    completedAt?: number;
+    targetVersion?: string;
+    installedVersion?: string;
+    code?: InstallFailureCode;
+    error?: string;
+    changed?: boolean;
+}
+type InstallFailure = InstallResult & {
+    ok: false;
+};
+export declare function firstPartyHarnessInstallDir(env?: NodeJS.ProcessEnv): string;
+export declare function firstPartyHarnessBinaryPath(env?: NodeJS.ProcessEnv): string;
+export declare function firstPartyHarnessPlatformKey(platform?: NodeJS.Platform, arch?: string): string | null;
+export declare function fetchVerifiedManifest(options?: InstallOptions): Promise<{
+    ok: true;
+    manifest: DaemonVersionManifest;
+} | InstallFailure>;
+export declare function isManagedFirstPartyHarnessReleasePath(binaryPath: string, env?: NodeJS.ProcessEnv): boolean;
+/** Read a single immutable binary/sidecar pair, never two different `current` targets. */
+export declare function getVerifiedInstalledFirstPartyHarness(options?: Pick<InstallOptions, 'env' | 'keys' | 'platform' | 'arch'>): {
+    binaryPath: string;
+    version: string | null;
+    verified: boolean;
+    exists: boolean;
+    provenance: HarnessProvenanceRecord | null;
+};
+export declare function readFirstPartyHarnessUpdateState(env?: NodeJS.ProcessEnv): FirstPartyHarnessUpdateState | null;
+export interface ActivateFirstPartyHarnessOptions {
+    binary: Buffer;
+    provenance: HarnessProvenanceRecord;
+    env?: NodeJS.ProcessEnv;
+    keys?: readonly ReleaseKey[];
+    platform?: NodeJS.Platform;
+    arch?: string;
+    allowDowngrade?: boolean;
+    onProgress?: (message: string) => void;
+    preserveUnknownInstalled?: boolean;
+    preserveExternalLink?: boolean;
+    /** Optional already verified signed manifest; retained as minimum-floor evidence. */
+    manifest?: DaemonVersionManifest;
+}
+/** Desktop's already-downloaded signed artifact uses the exact same transaction. */
+export declare function activateVerifiedFirstPartyHarnessArtifact(options: ActivateFirstPartyHarnessOptions): InstallResult;
+/** Signed-manifest check reads only; no lock, migration, state writes or login. */
+export declare function checkFirstPartyHarnessUpdate(options?: InstallOptions): Promise<{
+    ok: true;
+    installedVersion: string | null;
+    latestVersion: string;
+    channel: FirstPartyHarnessChannel;
+    updateAvailable: boolean;
+    binaryPath: string;
+    owner: 'managed' | 'external';
+    installedVerified: boolean;
+    minimumVersion: string;
+    lastUpdate: FirstPartyHarnessUpdateState | null;
+} | InstallFailure>;
+export declare function installFirstPartyHarness(options?: InstallOptions): Promise<InstallResult>;
+/** Rollback validates the retained immutable release and preserves its signature. */
+export declare function rollbackFirstPartyHarness(env?: NodeJS.ProcessEnv, options?: Pick<InstallOptions, 'keys'>): InstallResult;
+export declare function installedFirstPartyHarnessSize(env?: NodeJS.ProcessEnv): number | null;