@blamejs/core 0.11.17 → 0.11.18

package/CHANGELOG.md

@@ -8,6 +8,8 @@ upgrading across more than a few patches at a time.
 
 ## v0.11.x
 
+- v0.11.18 (2026-05-20) — **ML-DSA-65 release-signing key onboarded — `.mldsa.sig` sidecar lights up.** v0.11.17 was the first release the new pipeline published end-to-end, but the `.mldsa.sig` PQC sidecar was missing because the operator-side `RELEASE_PQC_SIGNING_KEY` setup hadn't been done yet. v0.11.18 onboards the keypair: `keys/release-pqc-pub.json` is committed in-tree, the matching private key lives only in the `npm-publish` environment's `RELEASE_PQC_SIGNING_KEY` secret, and `SECURITY.md` documents the SHA3-512 fingerprint + the operator-side verification recipe (no external verifier binary required — verifies via the framework's own vendored noble-post-quantum primitive). **Added:** *`keys/release-pqc-pub.json` — ML-DSA-65 release-signing public key committed in-tree* — Generated locally via `node scripts/generate-release-signing-key.js`; the matching private key was set as the `RELEASE_PQC_SIGNING_KEY` secret in the `npm-publish` GitHub Actions environment (same scope as `NPM_TOKEN`). The publish workflow's PQC sidecar step now finds both pieces present and computes a `<tarball>.mldsa.sig` for every release tarball. Self-verify-before-write inside `sign-release-artifact.js` catches a stale env-secret-vs-in-tree-pubkey mismatch — refuses to write a non-verifiable sig. · *`SECURITY.md` — `PQC release-signing key` fingerprint + verification recipe* — New SECURITY.md table records the algorithm (ML-DSA-65, FIPS 204), the in-tree public-key file path, and the SHA3-512 fingerprint (`ad6bee96…2ede`). Verification recipe uses the framework's own `b.pqcSoftware.ml_dsa_65.verify` — no external verifier binary required, no dependency on Sigstore's classical-crypto chain. Operators with a PQC-only verification posture have a self-contained path: `gh release download`, then `node -e` against the vendored noble-post-quantum primitive. **Changed:** *`Verifying release authenticity` — four trust roots, not three* — SECURITY.md's closing summary updated to count the ML-DSA-65 release-signing sidecar as the fourth independently-verifiable trust root, alongside SLSA L3 npm provenance + Sigstore-keyless SBOM signing + SSH-signed tags. Each remains verifiable without trusting any of the others; tampering with one is detected by the others. **References:** [FIPS 204 — ML-DSA](https://csrc.nist.gov/pubs/fips/204/final) · [FIPS 202 — SHA-3 + SHAKE](https://csrc.nist.gov/pubs/fips/202/final) · [RFC 9909 — ML-DSA in X.509 + CMS](https://www.rfc-editor.org/rfc/rfc9909.html) · [noble-post-quantum (vendored under lib/vendor)](https://github.com/paulmillr/noble-post-quantum)
+
 - v0.11.17 (2026-05-20) — **SLSA reusable workflow tag-pinned (the call requires a tag ref internally).** v0.11.7 through v0.11.16 each ship'd with the SLSA `generator_generic_slsa3` reusable workflow SHA-pinned and the publish workflow failed identically every time — masked by the SLSA workflow's cascading `continue-on-error: true` on each step until v0.11.16's diagnostic finally surfaced the real error: `Invalid ref: <40-hex>. Expected ref of the form refs/tags/vX.Y.Z`. The SLSA workflow's internal builder-fetch step refuses anything other than a tag ref for `BUILDER_REF`. Tag-pinned the callsite to `@v2.1.0`; updated the codebase-patterns `slsa-framework-action-not-sha-pinned` detector to allowlist this one callsite with the upstream-mitigation reasoning documented inline. **Fixed:** *SLSA reusable workflow callsite pinned to `@v2.1.0` (tag) instead of `@<sha>`* — The SLSA `generate-builder` action's builder-fetch step refuses non-tag refs for `BUILDER_REF` — the SHA we'd been pinning to since v0.11.7 was always failing here, hidden behind the SLSA workflow's step-level + workflow-level `continue-on-error: true` cascades. v0.11.16's diagnostic finally surfaced the actual error message. Switched to `@v2.1.0`. The repo-level `sha_pinning_required` actions policy was relaxed earlier so the tag pin is permitted. The `slsa-action-not-sha-pinned` codebase-patterns detector allowlists this one callsite — slsa-framework's tag-protection + immutable-release rules at their own org level mitigate the upstream-mutation risk the detector was originally guarding against. · *`slsa-action-not-sha-pinned` detector allowlists the npm-publish workflow callsite* — The detector continues to enforce SHA-pinning on every OTHER `slsa-framework/*` reusable-workflow callout repository-wide. Only the npm-publish workflow's `provenance` job is allowlisted, with the upstream tag-protection mitigation documented at the allowlist entry. New callsites still trip the detector. **References:** [SLSA `generate-builder` action — `Invalid ref` refusal](https://github.com/slsa-framework/slsa-github-generator/blob/v2.1.0/.github/actions/generate-builder/action.yml) · [slsa-framework `generator_generic_slsa3.yml` v2.1.0](https://github.com/slsa-framework/slsa-github-generator/blob/v2.1.0/.github/workflows/generator_generic_slsa3.yml)
 
 - v0.11.16 (2026-05-20) — **SLSA generator `private-repository: true` to override the false-positive privacy halt.** v0.11.15 cleared the SLSA outcome-AND chain via `continue-on-error: true`, then the underlying provenance generation FAILED with `Repository is private. The workflow has halted in order to keep the repository name from being exposed in the public transparency log. Set 'private-repository' to override.` — but `continue-on-error: true` masked it, the SLSA workflow reported success, no artifact was actually uploaded, and the downstream `publish-and-release` job's `Download SLSA provenance` step then failed. github.com/blamejs/blamejs is in fact public (gh api confirms `private: false, visibility: public`); SLSA's detection appears to walk workflow permissions rather than the repo's actual visibility. Passing `private-repository: true` overrides the detection and lets the workflow proceed to the Sigstore transparency-log write — which is the operator-desired behavior for a public-repo release. **Added:** *`SECURITY.md` — `Supply-chain transparency posture` subsection* — New SECURITY.md subsection documenting the Sigstore Rekor transparency-log writes (SLSA L3 attestation + cosign SBOM signatures), the operator-side rationale for the `private-repository: true` override, and the fork-operator escape hatch (set the input to `false` to halt transparency-log writes for private mirrors). Also calls out the framework's no-telemetry posture: every external endpoint primitive (DoH / ACME / OCSP / NTP / OSV-Scanner) runs through operator-supplied infrastructure; there is no framework-owned ingest channel. **Fixed:** *Pass `private-repository: true` to the SLSA reusable workflow* — The SLSA generic generator halts when its internal privacy detection thinks the repo is private. github.com/blamejs/blamejs is public per gh api repos/blamejs/blamejs's `visibility: public`, but SLSA's detection halts anyway (likely walking workflow permissions). Setting `private-repository: true` acknowledges the operator-side decision to write the transparency log entry regardless of detection. v0.11.15 cleared the outcome-AND chain but the upstream attest step was failing for this reason — `continue-on-error: true` masked it, the artifact never uploaded, and the downstream download failed. **References:** [SLSA generic generator inputs](https://github.com/slsa-framework/slsa-github-generator/blob/v2.1.0/.github/workflows/generator_generic_slsa3.yml) · [Sigstore Rekor transparency log](https://docs.sigstore.dev/logging/overview/)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@blamejs/core",
-  "version": "0.11.17",
+  "version": "0.11.18",
   "description": "The Node framework that owns its stack.",
   "license": "Apache-2.0",
   "author": "blamejs contributors",

package/sbom.cdx.json

@@ -2,10 +2,10 @@
   "$schema": "http://cyclonedx.org/schema/bom-1.5.schema.json",
   "bomFormat": "CycloneDX",
   "specVersion": "1.5",
-  "serialNumber": "urn:uuid:977499c0-aee7-4197-9b4d-c7af9fd7fda5",
+  "serialNumber": "urn:uuid:df277d76-8998-4935-acd7-542eefc40caa",
   "version": 1,
   "metadata": {
-    "timestamp": "2026-05-20T16:28:06.450Z",
+    "timestamp": "2026-05-20T17:38:57.164Z",
     "lifecycles": [
       {
         "phase": "build"
@@ -19,14 +19,14 @@
       }
     ],
     "component": {
-      "bom-ref": "@blamejs/core@0.11.17",
+      "bom-ref": "@blamejs/core@0.11.18",
       "type": "application",
       "name": "blamejs",
-      "version": "0.11.17",
+      "version": "0.11.18",
       "scope": "required",
       "author": "blamejs contributors",
       "description": "The Node framework that owns its stack.",
-      "purl": "pkg:npm/%40blamejs/core@0.11.17",
+      "purl": "pkg:npm/%40blamejs/core@0.11.18",
       "properties": [],
       "externalReferences": [
         {
@@ -54,7 +54,7 @@
   "components": [],
   "dependencies": [
     {
-      "ref": "@blamejs/core@0.11.17",
+      "ref": "@blamejs/core@0.11.18",
       "dependsOn": []
     }
   ]