@blamejs/core 0.6.64 → 0.6.65

package/CHANGELOG.md

@@ -8,6 +8,8 @@ upgrading across more than a few patches at a time.
 
 ## v0.6.x
 
+- **0.6.65** (2026-05-03) — `b.scheduler.parseCron` rejects step values exceeding the field's range. Pre-fix `*/99999 * * * *` was silently accepted and degenerated to "minute 0 of every hour" (because the for-loop adding values stopped at the first iteration when `step > range`); an operator typing the typo got a once-per-hour schedule when they probably meant once per N minutes. Now `_parseCronField` rejects with `scheduler/invalid-cron` when `step > (range.max - range.min + 1)`. The bound is inclusive so `*/60 * * * *` (= "minute 0 of every hour" written with a redundant explicit step) still accepts. **Tests** — 4 new layer-0 assertions: `*/60` accepts, `*/61` rejects, `*/99999` rejects (the silent-degenerate case), `* */25 * * *` rejects (step > 24-hour range). Smoke 7230 → 7234 / wiki e2e 178 / Linux 86.9s / eslint clean / shellcheck clean.
+
 - **0.6.64** (2026-05-03) — `b.credentialHash.verify` now enforces the same 16-byte minimum payload that `hash()` enforces. Pre-fix the asymmetry was a real risk: `hash()` refused to *create* a hash shorter than 16 bytes (`length < 16` rejected with `credential-hash/bad-opt`), but `verify()` silently accepted any payload length, including 1-byte payloads where the collision space is **256** — a hand-crafted envelope `{ magic, algoId, SHAKE256(targetPassword, 1)[0] }` would verify against the target password in microseconds. A storage bug or attacker tampering that truncated the stored envelope produced a verifiable but catastrophically weak hash; an attacker with DB write access who couldn't replace the hash outright could *truncate* it to a nearly-cleartext-equivalent value. Both ends now refuse short payloads symmetrically via the new `SHAKE256_MIN_LENGTH = 16` constant; verify returns false (with `payload-too-short` observability label) when the envelope's payload is < 16 bytes. Legitimate truncation that keeps the payload ≥ 16 bytes still verifies (the framework's design intentionally supports XOF variable-length digests via `params: { length: N }`); the bound only refuses hashes too short to provide meaningful collision resistance. **Tests** — 4 new layer-0 assertions on `b.credentialHash.verify` (1-byte attack envelope rejected, 15-byte rejected, 16-byte accepts, hash() rejects length 15). Smoke 7226 → 7230 / wiki e2e 178 / Linux 86.5s / eslint clean / shellcheck clean.
 
 - **0.6.63** (2026-05-03) — `b.parsers.toml.parse` enforces `maxDepth` on dotted-key paths. Pre-fix the parser walked arbitrarily deep table headers (`[a.b.c.d.e…]`) without applying the existing `maxDepth` (which only ran inside `_parseValue` for inline tables / arrays); a 10,000-segment path built a tree deep enough to stack-overflow the recursive `_normalize` walker post-parse. An attacker submitting a malicious TOML config to `b.config` would crash the framework at boot or whenever the file was reloaded. Now `_parseDottedKey` rejects a path with more than `maxDepth` segments via the same `toml/too-deep` error code already used for value-side depth. **Tests** — 4 new layer-0 assertions: 99-segment path under default depth accepts, 150-segment path rejects with `toml/too-deep`, 10K-segment path rejects (no stack overflow), `maxDepth: 1000` opt allows a 500-segment path. Smoke 7222 → 7226 / wiki e2e 178 / Linux 85.6s / eslint clean / shellcheck clean.

package/lib/scheduler.js

@@ -123,6 +123,21 @@ function _parseCronField(text, range) {
         throw new SchedulerError("scheduler/invalid-cron",
           "bad step '" + stepStr + "' in cron field '" + range.name + "'", true);
       }
+      // Reject step > field-range, even though the for-loop below would
+      // silently produce a single-value schedule (e.g. `*/99999` for
+      // minutes degenerates to "minute 0 of every hour"). An operator
+      // typing `*/99999` clearly meant something else; silent acceptance
+      // hides the typo and produces a schedule that fires once per hour
+      // when the operator probably wanted once per N minutes for small N.
+      // The bound is `range.max - range.min + 1` so e.g. minutes (0-59)
+      // accepts step up to 60 (inclusive — `*/60` is "minute 0 of every
+      // hour" written with a redundant step).
+      var rangeSize = range.max - range.min + 1;
+      if (step > rangeSize) {
+        throw new SchedulerError("scheduler/invalid-cron",
+          "step '" + stepStr + "' exceeds field range (" + rangeSize +
+          ") in cron field '" + range.name + "'", true);
+      }
       part = part.slice(0, stepIdx);
     }
     var lo, hi;

package/package.json

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

package/sbom.cyclonedx.json

@@ -2,10 +2,10 @@
   "$schema": "http://cyclonedx.org/schema/bom-1.5.schema.json",
   "bomFormat": "CycloneDX",
   "specVersion": "1.5",
-  "serialNumber": "urn:uuid:e636e4f9-23c0-41e8-8e78-f898e223c0e7",
+  "serialNumber": "urn:uuid:e379d7a4-43ef-4578-b4ba-31b6f69125f5",
   "version": 1,
   "metadata": {
-    "timestamp": "2026-05-03T14:18:03.806Z",
+    "timestamp": "2026-05-03T14:31:10.670Z",
     "lifecycles": [
       {
         "phase": "build"
@@ -19,14 +19,14 @@
       }
     ],
     "component": {
-      "bom-ref": "@blamejs/core@0.6.64",
+      "bom-ref": "@blamejs/core@0.6.65",
       "type": "library",
       "name": "blamejs",
-      "version": "0.6.64",
+      "version": "0.6.65",
       "scope": "required",
       "author": "blamejs contributors",
       "description": "The Node framework that owns its stack.",
-      "purl": "pkg:npm/%40blamejs/core@0.6.64",
+      "purl": "pkg:npm/%40blamejs/core@0.6.65",
       "properties": [],
       "externalReferences": [
         {
@@ -54,7 +54,7 @@
   "components": [],
   "dependencies": [
     {
-      "ref": "@blamejs/core@0.6.64",
+      "ref": "@blamejs/core@0.6.65",
       "dependsOn": []
     }
   ]