@blamejs/core 0.13.12 → 0.13.13

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md CHANGED
@@ -8,6 +8,8 @@ upgrading across more than a few patches at a time.
8
8
 
9
9
  ## v0.13.x
10
10
 
11
+ - v0.13.13 (2026-05-27) — **Archive extraction-path verification now refuses Windows reserved names, NTFS data streams, and trailing-dot/space per segment.** b.guardFilename.verifyExtractionPath (the per-entry gate b.archive.read.zip.extract / b.safeArchive run on every extracted file) checked traversal, absolute paths, drive-letter and UNC prefixes, null bytes, PATH_MAX overflow, and realpath containment — but not the per-segment Windows write-target hazards the disk validate / sanitize paths already reject. An archive entry named CON, NUL.txt, subdir/LPT1, file.txt:hidden, or secret.txt. stayed inside the extraction root, so the containment and realpath checks passed it, yet on Windows it would resolve to a device, write a hidden NTFS stream, or (after Windows strips the trailing dot/space) overwrite a sibling file. These are now refused: any path segment that collides with a Windows reserved device name, uses NTFS alternate-data-stream syntax (name:stream), or carries a trailing dot or leading/trailing whitespace. The checks are platform-unconditional — a verifier running on Linux still refuses names that are only dangerous on the Windows host that ultimately extracts the archive — with a per-check opt-out (reservedNamePolicy / adsPolicy / leadingTrailingPolicy: "allow") for Linux-only targets. **Security:** *`verifyExtractionPath` refuses per-segment Windows extraction hazards (reserved names / NTFS ADS / trailing dot-space)* — Closes a within-root write-target-redirection gap: an extracted entry could stay inside the destination yet, on Windows, resolve to a device (`CON` / `NUL` / `COM1` / `LPT1`), write a hidden alternate data stream (`file.txt:payload`), or overwrite a sibling after Windows strips a trailing dot/space (`config.`). The verification gate now rejects all three per path segment. Refusal is platform-unconditional (the verifier may run on a different OS than the extractor); set `reservedNamePolicy` / `adsPolicy` / `leadingTrailingPolicy` to `"allow"` to opt a check out on a Linux-only target. Single-entry, name-only residuals — 8.3 short-name aliasing, case-insensitive cross-entry collisions, and archive symlink/hardlink entry-target validation — remain the extract orchestrator's responsibility (it owns the case-folded seen-set and the link-target gate).
12
+
11
13
  - v0.13.12 (2026-05-27) — **Inbound MX listener now runs the connection-level gate cascade it documented — HELO identity, DNS blocklist, and greylisting.** b.mail.server.mx.create documented helo / rbl / greylist gate options, but the listener never invoked them — an operator who wired them got silent acceptance of mail those gates would have rejected. They are now wired into the live SMTP state machine: the HELO-identity gate evaluates at HELO/EHLO and refuses a spoofed or malformed identity with 550; the DNS-blocklist gate evaluates the connecting IP once per connection and refuses a listed source with 554; the greylisting gate defers a first-seen (ip, sender, recipient) tuple with a 450 tempfail so legitimate senders retry and pass. Each gate is skipped when the operator doesn't wire it. Because these gates do DNS and store lookups, the per-connection command pump was reworked to process commands asynchronously and strictly in arrival order, so pipelined commands (RFC 2920) cannot overtake a gate still resolving and the existing SMTP-smuggling and STARTTLS-stripping defenses are unchanged. The message-authentication gate (SPF/DKIM/DMARC alignment via b.guardEnvelope) needs the inbound SPF + DKIM verification results as inputs; that inbound-auth pipeline lands as a follow-up, and the documentation no longer implies that gate is active today. **Added:** *HELO-identity / RBL / greylist gates wired into `b.mail.server.mx`* — When wired, `opts.helo` (FCrDNS / HELO-shape / self-name checks) refuses a bad HELO identity at HELO/EHLO with 550; `opts.rbl` refuses a connecting IP found on a DNS blocklist with 554 (evaluated once per connection); `opts.greylist` defers a first-seen (ip, sender, recipient) tuple with 450 4.7.1. Their verdicts surface on the `rcpt_to` event (`rblListed`, `greylist`) and the `helo` event (`heloVerdict`), with dedicated `helo_gate_refused` / `rbl_refused` / `greylist_deferred` audit events. A gate the operator doesn't supply is skipped, never synthesized. **Changed:** *MX command pump processes commands asynchronously and in arrival order* — Gate evaluation involves DNS and store lookups, so the per-connection command pump now awaits each command before the next. Pipelined commands are serialized so a gate resolving cannot let a later command answer ahead of an earlier one; reply ordering, the bare-LF SMTP-smuggling refusal, and the STARTTLS-stripping defense are unchanged. No change to the listener's external behaviour when no gates are wired. **Deprecated:** *SPF/DKIM/DMARC-alignment gate documentation corrected to match what is active* — The `envelope` (SPF/DKIM/DMARC alignment) and `dmarc` gate options were documented as wireable but require inbound SPF + DKIM verification results the listener does not yet produce. They are removed from the documented option set until the inbound-authentication pipeline (composing `b.mail.spf` + `b.mail.dmarc` + DKIM verification) lands; run those checks on the delivered message via the agent handoff in the meantime.
12
14
 
13
15
  - v0.13.11 (2026-05-27) — **Test-suite reliability: replaced fixed-delay waits in the rate-limiter and scheduler suites with condition polling.** No runtime behaviour changes. The rate-limiter, scheduler, and websocket-channel test suites waited for asynchronous work to settle by draining a fixed number of event-loop ticks before asserting. Under heavily parallel CI that budget was occasionally too short, so an assertion read state before the async work (a cluster-backend counter update, a scheduler tick-claim) had landed — an intermittent failure unrelated to the code under test. Those waits now poll the observable condition (helpers.waitUntil) and exit as soon as it holds, with a generous upper bound, so they pass quickly on fast machines and reliably under load. A build gate is added so the fixed-tick-drain shape cannot be reintroduced. **Fixed:** *Flaky fixed-budget waits in the rate-limiter / scheduler / sandbox test suites made contention-tolerant* — The rate-limit-cluster and scheduler-exactly-once suites drained a fixed count of event-loop ticks before asserting on asynchronously-updated state; under contended CI the budget could expire before the work settled, producing intermittent failures. They now wait on the actual observable condition (a written response, a settled counter). The sandbox suite's success-path cases gave the worker a 5 s execution budget that cold worker-thread startup under heavily parallel Windows CI could just exceed; those are raised to the framework's 10 s ceiling. Affects test code only — no change to shipped framework behaviour. The unused tick-drain helper in the websocket-channel suite was removed. **Detectors:** *Build gate rejects the fixed-tick-drain wait shape in tests* — A new test-suite lint rule flags the counted microtask/tick-drain idiom (reassigning a promise to its own `.then()` in a loop to wait a fixed number of ticks), the sibling of the existing fixed-`setTimeout`-sleep rule. A single event-loop yield is unaffected; only the drain-as-wait shape is rejected, directing the wait to condition polling instead.
@@ -91,6 +91,20 @@ var WIN_RESERVED_NAMES = Object.freeze([
91
91
  "CLOCK$", "CONFIG$",
92
92
  ]);
93
93
 
94
+ // Windows folds the superscript digits U+00B9 / U+00B2 / U+00B3 to
95
+ // 1 / 2 / 3 when matching COM/LPT device names, so a superscript-digit
96
+ // form resolves to the same device. Built from numeric codepoints so
97
+ // the source stays pure-ASCII (guard-family rule).
98
+ var _SUPERSCRIPT_DIGIT_MAP = (function () {
99
+ var m = {};
100
+ m[String.fromCharCode(0xB9)] = "1";
101
+ m[String.fromCharCode(0xB2)] = "2";
102
+ m[String.fromCharCode(0xB3)] = "3";
103
+ return m;
104
+ })();
105
+ var _SUPERSCRIPT_DIGIT_RE = new RegExp("[" + String.fromCharCode(0xB9, 0xB2, 0xB3) + "]", "g"); // allow:dynamic-regex — superscript-digit codepoints from a numeric table
106
+
107
+
94
108
  // Path-traversal indicators (anchored matches on raw and percent-decoded
95
109
  // forms).
96
110
  var PATH_TRAVERSAL_RE = /(^|[/\\])\.\.($|[/\\])/;
@@ -243,7 +257,16 @@ function _normalizeNFC(s) {
243
257
  function _isWinReserved(name) {
244
258
  // Reserved-name check applies to the base (without extension) AND to
245
259
  // the entire leaf — both `CON` and `CON.txt` collide with the device.
246
- var upper = name.toUpperCase();
260
+ // Windows normalizes the superscript digits U+00B9 / U+00B2 / U+00B3
261
+ // to 1 / 2 / 3 when matching COM/LPT device names, so those superscript
262
+ // forms resolve to the same devices as COM1 / LPT3; fold them to ASCII
263
+ // before comparison so the spoofed forms are caught too. (Source stays
264
+ // pure-ASCII per the guard-family rule — the codepoints are escaped.)
265
+ // Fold COM/LPT superscript-digit spoofs to ASCII before matching
266
+ // (Windows treats them as the device). See _SUPERSCRIPT_DIGIT_* below.
267
+ var upper = name.toUpperCase().replace(_SUPERSCRIPT_DIGIT_RE, function (ch) {
268
+ return _SUPERSCRIPT_DIGIT_MAP[ch] || ch;
269
+ });
247
270
  for (var i = 0; i < WIN_RESERVED_NAMES.length; i += 1) {
248
271
  var r = WIN_RESERVED_NAMES[i];
249
272
  if (upper === r) return true;
@@ -952,6 +975,29 @@ var PATH_MAX_BYTES = 4096;
952
975
  * resolved absolute path on success; throws `GuardFilenameError` on
953
976
  * any refusal.
954
977
  *
978
+ * Per-segment Windows-extraction hazards are refused too — these are
979
+ * within-root write-target redirections / collisions that the
980
+ * containment + realpath checks structurally cannot see, so they need
981
+ * a name-level check the disk `validate` / `sanitize` paths already
982
+ * carry: a Windows reserved device name (`CON` / `NUL` / `COM1` / …,
983
+ * which resolves to the device), NTFS alternate-data-stream syntax
984
+ * (`name:stream`, which writes a hidden stream of the base file), and a
985
+ * trailing dot / leading-or-trailing whitespace (`secret.txt.`, which
986
+ * Windows strips so the entry overwrites an existing sibling). The
987
+ * checks are platform-unconditional — the verifier may run on Linux
988
+ * while extraction happens on Windows — and each has an opt-out for
989
+ * Linux-only targets (`reservedNamePolicy` / `adsPolicy` /
990
+ * `leadingTrailingPolicy: "allow"`), mirroring `validate`.
991
+ *
992
+ * Out of this primitive's scope (single-entry, name-only): 8.3 short-name
993
+ * aliasing (`PROGRA~1`), case-insensitive cross-entry collision
994
+ * (`Readme.txt` vs `README.TXT` on a case-preserving FS), and archive
995
+ * symlink/hardlink ENTRY-target validation. The first two are cross-entry
996
+ * properties and the third needs the entry's declared link target, which
997
+ * this function never sees — they belong to the extract orchestrator
998
+ * (`b.archive.read.zip.extract` / `b.safeArchive`), which owns the
999
+ * case-folded seen-set and the link-target gate.
1000
+ *
955
1001
  * Companion to `b.guardArchive.checkExtractionPath` (the string-only
956
1002
  * portable gate the guard-archive primitive keeps fs-free for use as
957
1003
  * a posture cascade member). `verifyExtractionPath` deliberately
@@ -964,8 +1010,13 @@ var PATH_MAX_BYTES = 4096;
964
1010
  * Operators rolling their own extract loop call it per entry.
965
1011
  *
966
1012
  * @opts
967
- * followSymlinks: boolean, // default false — symlink in the
1013
+ * followSymlinks: boolean, // default false — symlink in the
968
1014
  * // resolved path refuses unless set
1015
+ * reservedNamePolicy: string, // "allow" opts out of the Windows
1016
+ * // reserved-device-name segment check
1017
+ * adsPolicy: string, // "allow" opts out of the NTFS-ADS check
1018
+ * leadingTrailingPolicy: string, // "allow" opts out of the trailing-dot /
1019
+ * // leading-or-trailing-whitespace check
969
1020
  *
970
1021
  * @example
971
1022
  * var resolved = b.guardFilename.verifyExtractionPath(
@@ -1023,19 +1074,53 @@ function verifyExtractionPath(entryName, extractionRoot, opts) {
1023
1074
  throw new GuardFilenameError("filename.extraction-unc",
1024
1075
  "verifyExtractionPath: entryName starts with a UNC prefix");
1025
1076
  }
1026
- // `..` segment refuses — walk path components.
1077
+ // `..` segment refuses — walk path components. The same walk also
1078
+ // refuses per-segment Windows-extraction hazards the disk `validate`
1079
+ // / `sanitize` paths already catch but that string-containment +
1080
+ // realpath agreement cannot see, because they're WITHIN-root
1081
+ // collisions / write-target redirections rather than boundary
1082
+ // escapes. These checks are platform-UNCONDITIONAL: the verifier may
1083
+ // run on Linux while the archive is extracted on Windows, so a name
1084
+ // that's only dangerous on Windows must still be refused here.
1085
+ // Operators on a Linux-only target opt out per check, mirroring
1086
+ // `validate`'s policy vocabulary.
1027
1087
  var segs = normalized.split("/");
1028
1088
  for (var si = 0; si < segs.length; si += 1) {
1029
- if (segs[si] === ".." || segs[si] === "..\\" || segs[si] === "..%2f" || segs[si] === "..%5c") {
1089
+ var seg = segs[si];
1090
+ if (seg === ".." || seg === "..\\" || seg === "..%2f" || seg === "..%5c") {
1030
1091
  throw new GuardFilenameError("filename.extraction-traversal",
1031
1092
  "verifyExtractionPath: entryName contains .. segment");
1032
1093
  }
1033
1094
  // URL-encoded variants — explicit refusal so operators don't
1034
1095
  // need to percent-decode before passing the entry name in.
1035
- if (/%2e%2e/i.test(segs[si]) || /%c0%ae/i.test(segs[si])) {
1096
+ if (/%2e%2e/i.test(seg) || /%c0%ae/i.test(seg)) {
1036
1097
  throw new GuardFilenameError("filename.extraction-traversal-encoded",
1037
1098
  "verifyExtractionPath: entryName contains encoded .. segment");
1038
1099
  }
1100
+ if (seg === "" || seg === ".") continue; // separators / current-dir — nothing to name-check
1101
+ // Windows reserved device name (CON / NUL / COM1 / LPT1 / …): on
1102
+ // Windows the segment resolves to the device, redirecting the write.
1103
+ if (opts.reservedNamePolicy !== "allow" && _isWinReserved(seg)) {
1104
+ throw new GuardFilenameError("filename.extraction-reserved-name",
1105
+ "verifyExtractionPath: entryName segment " + JSON.stringify(seg) +
1106
+ " collides with a Windows reserved device name");
1107
+ }
1108
+ // NTFS alternate data stream (name:stream): on Windows the write
1109
+ // lands on a hidden stream of the base file, not a normal file.
1110
+ if (opts.adsPolicy !== "allow" && /:[^:\\/]+$/.test(seg)) {
1111
+ throw new GuardFilenameError("filename.extraction-ntfs-ads",
1112
+ "verifyExtractionPath: entryName segment " + JSON.stringify(seg) +
1113
+ " uses NTFS alternate-data-stream syntax (name:stream)");
1114
+ }
1115
+ // Trailing dot / leading-or-trailing whitespace: Windows silently
1116
+ // strips these, so `secret.txt.` or `secret.txt ` collides with an
1117
+ // existing sibling — an in-root overwrite the containment check
1118
+ // cannot see.
1119
+ if (opts.leadingTrailingPolicy !== "allow" && /^\s|\s$|\.$/.test(seg)) {
1120
+ throw new GuardFilenameError("filename.extraction-leading-trailing",
1121
+ "verifyExtractionPath: entryName segment " + JSON.stringify(seg) +
1122
+ " has leading/trailing whitespace or a trailing dot (Windows strips it)");
1123
+ }
1039
1124
  }
1040
1125
  // Resolve the destination path against the root via path.resolve
1041
1126
  // (string-level computation; no fs hits).
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@blamejs/core",
3
- "version": "0.13.12",
3
+ "version": "0.13.13",
4
4
  "description": "The Node framework that owns its stack.",
5
5
  "license": "Apache-2.0",
6
6
  "author": "blamejs contributors",
package/sbom.cdx.json CHANGED
@@ -2,10 +2,10 @@
2
2
  "$schema": "http://cyclonedx.org/schema/bom-1.5.schema.json",
3
3
  "bomFormat": "CycloneDX",
4
4
  "specVersion": "1.5",
5
- "serialNumber": "urn:uuid:cfe1e116-abd7-4631-96e5-8a2a865e2a16",
5
+ "serialNumber": "urn:uuid:b3c8f3dc-4ada-41d3-9b05-66ce6774c125",
6
6
  "version": 1,
7
7
  "metadata": {
8
- "timestamp": "2026-05-27T11:02:44.192Z",
8
+ "timestamp": "2026-05-27T12:37:28.862Z",
9
9
  "lifecycles": [
10
10
  {
11
11
  "phase": "build"
@@ -19,14 +19,14 @@
19
19
  }
20
20
  ],
21
21
  "component": {
22
- "bom-ref": "@blamejs/core@0.13.12",
22
+ "bom-ref": "@blamejs/core@0.13.13",
23
23
  "type": "application",
24
24
  "name": "blamejs",
25
- "version": "0.13.12",
25
+ "version": "0.13.13",
26
26
  "scope": "required",
27
27
  "author": "blamejs contributors",
28
28
  "description": "The Node framework that owns its stack.",
29
- "purl": "pkg:npm/%40blamejs/core@0.13.12",
29
+ "purl": "pkg:npm/%40blamejs/core@0.13.13",
30
30
  "properties": [],
31
31
  "externalReferences": [
32
32
  {
@@ -54,7 +54,7 @@
54
54
  "components": [],
55
55
  "dependencies": [
56
56
  {
57
- "ref": "@blamejs/core@0.13.12",
57
+ "ref": "@blamejs/core@0.13.13",
58
58
  "dependsOn": []
59
59
  }
60
60
  ]