@blamejs/core 0.9.9 → 0.9.12

package/CHANGELOG.md

@@ -8,6 +8,9 @@ upgrading across more than a few patches at a time.
 
 ## v0.9.x
 
+- v0.9.12 (2026-05-13) — **Republish of v0.9.10 / v0.9.11 — `npm audit signatures` grep widened for the npm-message variant that fires post-v0.9.11**. The publish workflow's "Verify npm registry signing chain" step treats an empty-tree result as success (the framework's zero-runtime-deps posture means `npm audit signatures --omit dev` finds nothing to audit). The exact phrasing has drifted across npm versions: older npm prints `found no installed dependencies to audit`; newer npm (the version on the GH Actions runner post-v0.9.11) prints `found no dependencies to audit that were installed from a supported registry`. The shell guard's grep only matched the older phrasing, so v0.9.11's publish failed at the audit-signatures gate even though every other step succeeded. The grep is now `no (installed )?dependencies to audit` — covers both known empty-tree variants. v0.9.10's broken-smoke fix (added `npm install` before smoke) plus v0.9.12's audit-signatures-grep fix together complete the publish-pipeline repair. v0.9.12 is functionally identical to v0.9.10's intended surface. Operators stuck at v0.9.9 (because v0.9.10 + v0.9.11 never reached the npm registry) jump directly to v0.9.12.
+- v0.9.11 (2026-05-13) — **Republish of v0.9.10 — npm-publish.yml now installs devDependencies before smoke**. v0.9.10's tag was pushed and the GitHub release published, but `npm-publish.yml`'s Framework-smoke step ran `node test/smoke.js` without first running `npm install`. The new bundler-output gate added in v0.9.10 requires `esbuild` (a devDependency) to be present, so the publish workflow failed at the smoke step before reaching the publish step — the v0.9.10 npm tarball was never published. The fix adds `npm install --no-audit --no-fund` to `.github/workflows/npm-publish.yml` directly before the smoke step (mirroring the same fix already present in `.github/workflows/ci.yml`). Operators consuming via `npm install @blamejs/core` should pull v0.9.11; functionally identical to the intended-v0.9.10 surface. Zero runtime deps invariant preserved.
+- v0.9.10 (2026-05-13) — **Bundler-output e2e gate** — `test/layer-5-integration/bundler-output.test.js`. Bundles the framework via `esbuild --bundle --platform=node` (also `--minify`), runs the bundled consumer, and asserts the four-layer vendor-data integrity surface (dual-hash + SLH-DSA signature + canary) survives bundling. The PSL canary roundtrips through `b.publicSuffix.isPublicSuffix(...)` after bundle exec — proves the `.data.js` payloads physically reached the bundle bytes, not just the runtime require shape. Plus a byte-search sentinel that grep's the produced bundle for the canary tokens directly (defense-in-depth, independent failure mode from the runtime path). Plus a SEA gate (Linux + Node >= 22 only) that runs `--experimental-sea-config` + `postject` to produce an actual single-executable binary and runs it. The whole class of bugs — dynamic-require breaks bundling, SEA `assets` map missing, esbuild static-trace failures — is now smoke-gated. Had this test existed when v0.9.8 published, it would have refused that release at smoke-time (the v0.9.8 dynamic-require defect produced bundles that exited with `vendor-data/module-missing` on first vendor-data access; this gate's `BUNDLE-OK psl=co.uk entries=3` stdout-check refuses that exit). No framework-surface changes.
 - v0.9.9 (2026-05-13) — **`b.vendorData`: replace dynamic `require(variable)` with static literal-string requires so SEA / esbuild / pkg bundling actually works**. v0.9.8 shipped `b.vendorData` to remove `__dirname`-relative `fs.readFileSync` calls and make the loader packaging-mode-invariant. The implementation looked up each `.data.js` module via `require(entry.module)` where `entry.module` was read from a frozen lookup table — a *dynamic* require, opaque to every bundler's static-analysis pass. esbuild, webpack, ncc, rollup, pkg, nexe, Bun's bundler, and Deno's bundler all trace `require("./literal")` calls; none of them trace `require(variable)`. Result: the three `.data.js` payload modules never made it into SEA / pkg / esbuild bundles, defeating the v0.9.8 promise at boot ("vendor-data/module-missing" thrown by every consumer that bundled the framework). v0.9.9 replaces the lookup with a `_MODULES` table whose three values are each a top-level `var X = require("./vendor/<name>.data")` — literal string, statically traceable. Caught by hermitstash-sync operator review post-v0.9.8 publish. Net surface change: zero (the public `b.vendorData.get` / `getAsString` / `verifyAll` / `inventory` shape is identical); the fix is internal-only. **New codebase-patterns drift detector** `testNoDynamicRequires` refuses any future `require(variable)` in `lib/`; legitimate operator-extensibility points (`b.cli`, migrations, seeders) carry an explicit `allow:dynamic-require` marker with rationale. **Operators upgrade from v0.9.8 to v0.9.9 if they bundle the framework via SEA / esbuild / pkg / Bun-compile** — direct `node` consumers were unaffected (Node's runtime require always resolves dynamic strings correctly).
 - v0.9.8 (2026-05-13) — **`b.vendorData` — packaging-mode-invariant + signed + canary-guarded loader for vendored data files**. The three plaintext vendor data files (`public-suffix-list.dat`, `common-passwords-top-10000.txt`, `bimi-trust-anchors.pem`) are now loaded via inline `Buffer.from(base64)` modules (`<name>.data.js`), eliminating the `__dirname`-relative `fs.readFileSync` paths that broke under Single Executable Application (SEA), `pkg`, `nexe`, esbuild, Bun compile, Deno compile, and AWS Lambda layer bundling. Every load runs four orthogonal integrity checks before returning a byte: SHA-256 + SHA3-512 + SLH-DSA-SHAKE-256f signature against the maintainer's pinned public key (`lib/vendor/.vendor-data-pubkey`) + in-payload canary entry that the parsed structure must surface. Tamper at any layer throws `VendorDataError` at module-load — fail-fast rather than first-request-touches-PSL surprise. **Public API**: `b.vendorData.get(name)` returns the verified Buffer; `b.vendorData.getAsString(name)` returns UTF-8 string; `b.vendorData.verifyAll()` runs all four layers across every registered vendor data file and is invoked at framework boot; `b.vendorData.inventory()` returns per-file metadata (name, source, fetchedAt, sha256, sha3_512, signedBy, canary, byteLength, description) for compliance reporting + SBOM emission. **Migrated call sites**: `b.publicSuffix` (PSL load), `b.auth.password._loadBundledCommon` (common-passwords), `b.mail.bimi` (trust anchors) now route through `b.vendorData` — removes any downstream consumer's need to patch the loader for SEA / bundler builds. **Maintainer signing infrastructure**: vendor data files signed at refresh time by a maintainer-held SLH-DSA-SHAKE-256f keypair (private key stays in `.keys/` and is never committed; public key ships in `lib/vendor/.vendor-data-pubkey` in every npm tarball). Adds a fourth orthogonal trust root alongside SSH-signed release tags + SLSA L3 npm provenance + Sigstore-keyless SBOM signatures. **MANIFEST.json**: per-vendor-data entry gains `runtime_artifact` + `integrity_layers` + dual-file `hashes` (raw `.dat/.txt/.pem` + companion `.data.js`). **New scripts**: `scripts/vendor-data-keygen.js` (one-time keypair generation), `scripts/vendor-data-gen.js` (generator invoked by `scripts/vendor-update.sh --refresh-data`).
 - v0.9.7 (2026-05-13) — **SECURITY.md: release-tag verification path documented + signed-tag invariant from v0.9.7+**. SECURITY.md gains a "Verifying release authenticity" section documenting how operators verify a release tag's authenticity independently of GitHub's UI. The maintainer Ed25519 SSH signing key fingerprint (`SHA256:5oF/XWhFpMde9TRfEX2GAHiApAq/MXOS4vti5zQbD7g`) is published alongside the public-key retrieval URL (`https://github.com/dotCooCoo.keys`) and a `git tag -v` recipe that bypasses the "Verified" badge. From v0.9.7 onward, every release tag is an annotated SSH-signed tag; the repository's `release-tags` ruleset's `required_signatures` rule refuses any unsigned or lightweight tag push at the server side. Earlier tags (v0.9.6 and prior) remain as lightweight commits and don't verify via `git tag -v`; they continue to verify via the SLSA L3 npm provenance + Sigstore-keyless SBOM signatures already attached to those releases (the `cosign verify-blob` recipe is in the same SECURITY.md section). No framework-surface changes; this release ships the documentation + invariant only.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@blamejs/core",
-  "version": "0.9.9",
+  "version": "0.9.12",
   "description": "The Node framework that owns its stack.",
   "license": "Apache-2.0",
   "author": "blamejs contributors",
@@ -74,6 +74,8 @@
     "prepack": "node scripts/check-pack-against-gitignore.js",
     "check:vendor-currency": "node scripts/check-vendor-currency.js"
   },
-  "dependencies": {},
-  "devDependencies": {}
+  "devDependencies": {
+    "esbuild": "0.28.0",
+    "postject": "1.0.0-alpha.6"
+  }
 }

package/sbom.cdx.json

@@ -2,10 +2,10 @@
   "$schema": "http://cyclonedx.org/schema/bom-1.5.schema.json",
   "bomFormat": "CycloneDX",
   "specVersion": "1.6",
-  "serialNumber": "urn:uuid:cd59dfcc-1a4e-488c-b7fa-8f4b9ac61c45",
+  "serialNumber": "urn:uuid:d4b77800-e22b-4c36-be2e-cecdcb0c34da",
   "version": 1,
   "metadata": {
-    "timestamp": "2026-05-13T14:31:49.840Z",
+    "timestamp": "2026-05-13T16:54:10.092Z",
     "lifecycles": [
       {
         "phase": "build"
@@ -19,14 +19,14 @@
       }
     ],
     "component": {
-      "bom-ref": "@blamejs/core@0.9.9",
+      "bom-ref": "@blamejs/core@0.9.12",
       "type": "library",
       "name": "blamejs",
-      "version": "0.9.9",
+      "version": "0.9.12",
       "scope": "required",
       "author": "blamejs contributors",
       "description": "The Node framework that owns its stack.",
-      "purl": "pkg:npm/%40blamejs/core@0.9.9",
+      "purl": "pkg:npm/%40blamejs/core@0.9.12",
       "properties": [],
       "externalReferences": [
         {
@@ -54,7 +54,7 @@
   "components": [],
   "dependencies": [
     {
-      "ref": "@blamejs/core@0.9.9",
+      "ref": "@blamejs/core@0.9.12",
       "dependsOn": []
     }
   ]