import-limits.ts

1// Import-path resource bounds — audit fixes MV-4 (decompression bomb) and2// MV-5 (unbounded file/string allocation).3//4// Every untrusted import surface (pasted PeachScript/backup strings, .peach /5// .json files, Codex PDFs) must check these BEFORE allocating or inflating.67export const IMPORT_LIMITS = {8  /** Hard ceiling on any decompressed output (zstd sections, pako inflate). */9  MAX_DECOMPRESSED_BYTES: 64 * 1024 * 1024, // 64 MiB10  /** Ceiling on an attacker-declared pre-decompress length field. */11  MAX_DECLARED_LENGTH: 64 * 1024 * 1024, // 64 MiB12  /** Max PDF file size accepted by the Codex importer. Current-generation13    *  Codexes (350-byte chunks) run far more pages for the same vault — real14    *  ones exceed 40 MiB. Render memory is bounded separately by the page15    *  dimension and page-count caps in pdf-import.ts, not by file size. */16  MAX_PDF_BYTES: 64 * 1024 * 1024, // 64 MiB17  /** Max raw JSON/CSV/PeachScript string length accepted by import/restore. */18  MAX_JSON_BYTES: 10 * 1024 * 1024, // 10 MiB19  /**20   * Max entries one parse may yield. A 10 MiB input of minimal rows expands to21   * ~25x its size in ImportableEntry objects, which is enough to kill an MV322   * service worker. Matches the sync layer's MAX_ENTRY_COUNT.23   */24  MAX_IMPORT_ENTRY_COUNT: 100_000,25} as const;2627/**28 * Error code shared by all import-path size rejections. The import UI maps29 * it to a user-readable message ("This file is too large to be a Peach30 * backup …") instead of surfacing a raw thrown error.31 */32export const IMPORT_TOO_LARGE = "IMPORT_TOO_LARGE";3334export function importTooLarge(detail: string): Error {35  return new Error(`${IMPORT_TOO_LARGE}: ${detail}`);36}