@blamejs/core 0.16.13 → 0.16.14

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.16.x
10
10
 
11
+ - v0.16.14 (2026-07-11) — **Make the object-store single-backend shorthand work for remote backends, and return a string time zone (not an array) when importing an iCalendar event — two defects found by covering previously-untested configuration and import branches.** Covering more configuration and import branches surfaced two genuine defects, now fixed at the root. The documented object-store single-backend shorthand — b.storage.init({ backend: 'sigv4' | 'gcs' | 'azure-blob' | 'http-put', ... }) — never worked for a remote backend: it forwarded the caller's options with the backend key intact, but the object-store backend builder resolves protocol, so the backend was constructed with no protocol and initialization threw a missing-protocol error. Only the local shorthand (which happens to name the key correctly) worked. The shorthand now translates backend to protocol, so all four remote backends construct as documented. And b.calendar.fromIcal mapped a DTSTART;TZID=<zone> parameter to a JSCalendar timeZone that was an array (['America/New_York']) instead of the string RFC 8984 §4.7.1 requires — it only round-tripped by accident because a single-element array coerces to a string; the parameter is now unwrapped to a scalar string. **Fixed:** *b.storage remote single-backend shorthand constructs the backend* — b.storage.init({ backend: 'sigv4' | 'gcs' | 'azure-blob' | 'http-put', ... }) forwarded the options with the backend key, but the object-store backend builder reads protocol — so the default backend had no protocol and initialization threw a missing-protocol ObjectStoreError. The remote shorthand never worked (only the { backend: 'local' } form, which names protocol correctly under the hood, did). The shorthand now maps backend to protocol and drops the backend key, so all four remote backends build as documented. · *b.calendar.fromIcal returns a string time zone for DTSTART/DUE;TZID* — An imported event's DTSTART;TZID=<zone> (or a task's DUE;TZID) mapped to a JSCalendar timeZone that was a single-element array rather than the string RFC 8984 §4.7.1 requires. It happened to round-trip back through toIcal because a one-element array coerces to a string, but consumers reading timeZone as a string saw an array. The property parameter is now unwrapped to its scalar first value.
12
+
11
13
  - v0.16.13 (2026-07-11) — **Make SD-JWT VC verification accept a raw JWK issuer key (its own documented common path), and emit the SMTP command-smuggling audit on a NUL-byte injection — two defects found by covering previously-untested verifier and inbound-server branches.** Covering the uncovered verifier and adversarial-input branches of two more subsystems surfaced two genuine defects, now fixed at the root. b.auth.sdJwtVc.verify rejected a valid credential when the issuerKeyResolver returned a raw JWK object — the very path the code's own comment calls the common one — because the JWK was handed straight to node:crypto.verify, which cannot consume a bare JWK, so verification threw a low-level type error instead of validating; the resolver's JWK is now imported to a key object before verification, matching the holder key-binding path. And the inbound SMTP server refused a command line containing a NUL byte (correct) but never emitted the command-smuggling audit event it emits for bare-CR / bare-LF injection, because it checked for the wrong error code; the audit now fires so a NUL-injection attempt is recorded for forensic triage. A misleading comment in the permissions MFA gate that advertised a non-existent no-freshness-window escape hatch is corrected — the freshness window is always enforced by design. **Fixed:** *b.auth.sdJwtVc.verify accepts a raw JWK from issuerKeyResolver* — When the issuerKeyResolver returned a JWK object — described in the code as the common path — the JWK was passed directly to node:crypto.verify, which requires a key object, so a valid credential failed verification with a raw ERR_INVALID_ARG_TYPE rather than validating. The resolver's JWK is now imported to a public key object (with the existing algorithm/key-type cross-check preserved) before verification, mirroring the holder key-binding JWT path. Verification succeeds for EC and Ed25519 JWK resolvers. · *Corrected a misleading comment in the permissions MFA freshness gate* — A comment in the requireMfa gate described mfaWindowMs: Infinity as an operator escape hatch for a no-freshness-window pass-through. No such escape hatch exists — both the role- and route-level validators reject a non-finite mfaWindowMs, so MFA freshness is always enforced (defaulting to 15 minutes). Enabling it would let a stolen long-lived cookie with a stale mfaAt bypass the gate. The comment now states the freshness window is always enforced; behavior is unchanged. **Security:** *SMTP inbound server records a command-smuggling audit on NUL-byte injection* — The inbound MX server's command handler refused a command line containing a NUL byte with a 500, but the branch meant to emit the mail.server.mx.smtp_smuggling_detected audit checked for the error code guard-smtp-command/nul-byte while the guard actually raises guard-smtp-command/nul. As a result a NUL-injection command was rejected but not recorded, unlike bare-CR / bare-LF smuggling which was audited. The code match is corrected, so a NUL-byte command-smuggling attempt now produces the forensic audit event.
12
14
 
13
15
  - v0.16.12 (2026-07-11) — **Restore the static server's drive-by-execution defense, stop the retention sweep from aborting on subject-scoped rules, make wss:// connections to IP addresses work, and return a verdict instead of throwing on a malformed OpenPGP signature — four defects found by covering previously-untested error and adversarial branches.** Writing behavioral tests for the uncovered error and adversarial branches of the framework's most under-tested files surfaced four genuine defects, now fixed at the root. The static file server's safeAttachmentForRiskyMimes option — the drive-by-execution defense that forces Content-Disposition: attachment for risky inline types (text/html, image/svg+xml, application/javascript) — was silently inert: it was read from a value bag that only carries known-default keys, and this option has no default entry, so it always evaluated to false and the whole defense was dead code. The retention sweep threw and aborted entirely whenever a retention rule with a subjectField met a row with a subject value, because it called a lazily-required module as if it were already resolved. A wss:// connection to an IP-address host threw synchronously and was unusable, because the client set the TLS SNI to the IP literal, which the TLS stack forbids. And b.mail.crypto.pgp.verify threw on a truncated or malformed signature integer instead of returning its documented { ok: false } verdict, so a consumer iterating over untrusted signatures crashed rather than getting a negative result. A static gate now flags any option read from a defaults-applied value bag when that option has no default entry, so the static-server class cannot recur. **Fixed:** *Retention sweep no longer aborts on subject-scoped rules* — A retention rule declared with a subjectField consults the subject-level legal-hold registry when a candidate row carries a subject value. That path called the legal-hold module as though it were already resolved, but it is a lazily-required getter that must be invoked to load the module — so the call threw a TypeError, which the sweep converted into a SWEEP_FAILED and aborted the entire run. The getter is now invoked correctly, so subject-scoped retention sweeps proceed. · *wss:// connections to an IP-address host work* — Connecting the WebSocket client to a wss:// URL whose host is an IP literal threw ERR_INVALID_ARG_VALUE synchronously, because the client set the TLS SNI servername to the IP literal, which RFC 6066 and the Node TLS stack forbid. SNI is now sent only for hostname targets and omitted for IP literals; certificate identity is still verified against the address. **Security:** *Static server's safeAttachmentForRiskyMimes drive-by-execution defense works* — b.staticServe's documented safeAttachmentForRiskyMimes option forces Content-Disposition: attachment for risky inline MIME types (text/html, image/svg+xml, application/javascript) so a browser can't execute an operator-hosted file inline. It was read from the option bag produced by applyDefaults, which strips every key absent from the defaults table — and this option is not a defaults key — so it was always undefined and the defense never engaged. It is now read directly from the caller's options, so enabling it forces the attachment disposition as documented. Operators who set it were relying on a defense that did nothing; it is now active. · *b.mail.crypto.pgp.verify returns a verdict on a malformed signature instead of throwing* — verify() threw MailCryptoError('mail-crypto/pgp/bad-mpi') on a truncated or malformed signature integer, unlike every other malformed-signature path (bad armor, packet parse, hash mismatch), which returns { ok: false, code, reason }. A consumer looping over untrusted signatures and branching on .ok would crash on a crafted input rather than receive a negative verdict. Malformed signature integers now route through the same failure path and return { ok: false }. **Detectors:** *applydefaults-dropped-opt* — A static gate flags any option read from the result of applyDefaults(opts, DEFAULTS) when that option is absent from the DEFAULTS table — the exact shape that silently disabled the static server's attachment defense. The result of applyDefaults carries only the defaults' keys, so such a read is always undefined. The fix is to read the option from the caller's opts directly, or to add it to the defaults table.
package/lib/calendar.js CHANGED
@@ -1116,7 +1116,14 @@ function _firstParamValue(prop, paramName) {
1116
1116
  if (!prop) return null;
1117
1117
  var first = Array.isArray(prop) ? prop[0] : prop;
1118
1118
  if (!first || !first.params) return null;
1119
- return first.params[paramName] || null;
1119
+ // b.safeIcal exposes each property parameter as a (possibly
1120
+ // multi-valued) array. Consumers here want a scalar — a TZID maps to
1121
+ // the JSCalendar `timeZone` String (RFC 8984 §4.7.1), not an array.
1122
+ // Unwrap to the first element so `timeZone` is a plain string that
1123
+ // round-trips through toIcal's `DTSTART;TZID=<zone>` emission.
1124
+ var v = first.params[paramName];
1125
+ if (v === undefined || v === null) return null;
1126
+ return Array.isArray(v) ? (v.length > 0 ? v[0] : null) : v;
1120
1127
  }
1121
1128
 
1122
1129
  function _icalRruleToJscal(rrule) {
package/lib/storage.js CHANGED
@@ -162,9 +162,15 @@ function _normalizeConfig(opts) {
162
162
  };
163
163
  }
164
164
  if (opts.backend === "http-put" || opts.backend === "sigv4" || opts.backend === "gcs" || opts.backend === "azure-blob") {
165
- // Forward as-is; user provided a single-backend spec for a remote protocol
165
+ // Forward the single-backend spec, translating the `backend` shorthand
166
+ // into the `protocol` key the object-store adapter builds against — the
167
+ // local branch above already spells it `protocol`, and buildBackend keys
168
+ // off `protocol`, so forwarding `backend` verbatim left the default
169
+ // backend without a protocol and failed to build.
170
+ var remoteCfg = Object.assign({}, opts, { protocol: opts.backend, name: undefined });
171
+ delete remoteCfg.backend;
166
172
  return {
167
- backends: { "default": Object.assign({}, opts, { name: undefined }) },
173
+ backends: { "default": remoteCfg },
168
174
  defaultClassification: null,
169
175
  refuseUnclassified: false,
170
176
  };
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@blamejs/core",
3
- "version": "0.16.13",
3
+ "version": "0.16.14",
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:b90a5fae-dd42-4003-9780-e63a6ebf948e",
5
+ "serialNumber": "urn:uuid:bdc2a663-f665-4018-9260-017bb1ddc890",
6
6
  "version": 1,
7
7
  "metadata": {
8
- "timestamp": "2026-07-11T13:08:36.250Z",
8
+ "timestamp": "2026-07-11T16:22:28.907Z",
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.16.13",
22
+ "bom-ref": "@blamejs/core@0.16.14",
23
23
  "type": "application",
24
24
  "name": "blamejs",
25
- "version": "0.16.13",
25
+ "version": "0.16.14",
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.16.13",
29
+ "purl": "pkg:npm/%40blamejs/core@0.16.14",
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.16.13",
57
+ "ref": "@blamejs/core@0.16.14",
58
58
  "dependsOn": []
59
59
  }
60
60
  ]