@blamejs/core 0.18.56 → 0.18.57

package/CHANGELOG.md

@@ -8,6 +8,28 @@ upgrading across more than a few patches at a time.
 
 ## v0.18.x
 
+- v0.18.57 (2026-08-28) — **A mail listener refused the key-agreement group TLS 1.3 makes mandatory, and negotiated a weaker one than it would have with no policy at all.** `b.mail.server.tls.context` applied the outbound key-agreement preference to a server context. A flat colon-separated list is an offer order to a client and an ACCEPT SET to a server, so the listener refused every group the list did not name — including `secp256r1`, which RFC 8446 §9.1 makes mandatory to implement. On an SMTP listener a refused handshake is not a downgrade to cleartext: the peer meets `530 5.7.0 Must issue a STARTTLS command first` on any retry and the message stays queued until it bounces.
+
+The same flatness collapsed HelloRetryRequest ordering, so a peer offering `X25519:X25519MLKEM768` was served X25519 — while the same peer against a context with no policy at all was pulled up to the hybrid. Applying the list made the negotiated group worse than applying nothing.
+
+Also: a TLS-RPT report is now sent to a receiver that publishes its `rua` address in the DNS absolute form, where it was silently never sent. **Fixed:** *A mail listener accepts every registered ECDHE group, and still prefers a post-quantum hybrid (#677)* — `b.network.tls.keyAgreementGroups` returns a flat colon-separated list. That is the right shape for a client, where node sends a key share for the first entry and takes the first mutually-supported group. OpenSSL 3.5 reads the same string on a server as the set of groups it will accept AT ALL, and only tuples separated by `/` as an order between them.
+
+So the listener refused `secp256r1`, `secp384r1`, `secp521r1` and `X448` outright. RFC 8446 §9.1 makes `secp256r1` mandatory to implement and only recommends X25519, so a fully conforming peer with a NIST-only group policy could not complete a handshake at all — and on an SMTP listener that is lost mail rather than a downgrade, because the peer meets `530 5.7.0 Must issue a STARTTLS command first` on any cleartext retry.
+
+It also lost post-quantum coverage, which is the reverse of the intent. A peer offering `X25519:X25519MLKEM768` was served X25519, where the same peer against a context with no list was pulled up to `X25519MLKEM768` by a HelloRetryRequest.
+
+`b.network.tls.serverKeyAgreementGroups` is the server form, and `b.mail.server.tls.context` uses it. It emits tuples — every ML-KEM hybrid first, then every registered ECDHE curve — so the listener still prefers a hybrid and will spend a retry to reach one, while accepting any group RFC 8446 §4.2.7 registers. `SecP256r1MLKEM768` stays accepted, which the runtime's own server default refuses, so applying a policy still buys something. The finite-field `ffdhe*` groups remain absent deliberately: refusing those on a listener is a policy worth keeping, refusing registered ECDHE curves is not.
+
+The interoperability curves widen the SHIPPED DEFAULT only. An operator who called `b.network.tls.pqc.setKeyShares` narrowed the policy deliberately — the FIPS example in that module drops the X25519-based groups — and their list is taken as written on a listener too. Adding the curves back there would have let a peer negotiate exactly what was excluded, with the restriction holding outbound and silently not holding inbound. A narrowed listener may refuse a conforming peer; that is a choice the operator made and can see, where the reverse would not be.
+
+Every configured rank becomes its own tuple, because ordering exists only between tuples: two groups sharing one are a set the server takes in whatever order the handshake reaches them, so `["secp384r1", "X25519"]` packed together would negotiate X25519 despite secp384r1 ranking first.
+
+An operator-supplied `ecdhCurve` is still honoured verbatim, and a malformed one still refused rather than replaced. · *A TLS-RPT report reaches a receiver that publishes its address absolutely (#676)* — `b.network.smtp.tlsRpt.submit` refused a `rua=mailto:` target written in the DNS absolute form, with `mailto: target is not a valid RFC 5322 addr-spec`.
+
+That address is published by the receiving domain in its own `_smtp._tls` record. It is not input from the operator running the sender, and a peer spelling its hostname absolutely is using the form RFC 1035 §3.1 defines — a zone file writes it that way routinely. The effect was that a receiver asking to be told about TLS failures was never told, the report owed under RFC 8460 was not sent, and nothing signalled that it had been dropped.
+
+One trailing dot is now folded off before the address is validated. That cannot turn a valid address into a different valid one, because a trailing dot is not legal in an addr-spec domain, so a name carrying one has exactly one reading. The result records `published` beside `to`, so an operator can see what the peer wrote and what was used. A doubled trailing dot is still refused. · *The mail TLS test file exits when it finishes* — It printed its OK line and then hung, because the handshake-measuring helper closed its two listeners but never destroyed the sockets they had already accepted — `server.close()` stops a listener accepting and leaves established connections alone. Four sockets survived each run and held the event loop open, so the file could not be used in a batch without stalling whatever invoked it.
+
 - v0.18.56 (2026-08-27) — **A CSRF exemption turned on a header the attacker writes, and a certificate renewal reached four mail listeners but not the fifth.** `csrfProtect`'s `skipStateless` waived the token check for any request carrying an `Authorization` header. Presence is not authenticity: an attacker composing a cross-site request writes their own headers. Worse, the header says nothing about which credential authenticated the request, and `attachUser` with `tokenFrom: "both"` reads the cookie first — so a request carrying both was authenticated by exactly the ambient credential the gate protects, and skipped the gate on a header nobody read. The exemption now turns on the absence of a cookie, and it no longer waives the origin check.
 
 The mail listeners had two cases of the same shape: a value read once at construction that the operator changes while the server runs. ManageSieve captured `opts.tlsContext`, so a certificate renewal reached its four siblings and not it — and nothing reported that, because the watcher fired and the context rebuilt exactly as expected. `mail.server.mx` captured `localDomains`, so a withdrawn domain kept drawing 250 at RCPT until a restart while every management surface agreed it was gone.

package/lib/constants.js

@@ -279,6 +279,38 @@ var TLS_GROUP_PREFERENCE = Object.freeze([
 
 var TLS_GROUP_CURVE_STR = TLS_GROUP_PREFERENCE.join(":");
 
+// ---- Inbound (server) accept-groups ----
+//
+// The list above is an OFFER ORDER, which is what a client needs. A server
+// reads the same flat string as its ACCEPT SET: OpenSSL 3.5 treats a
+// colon-separated list as the groups it will accept AT ALL, and only tuples
+// separated by `/` as an order between them. Applying the outbound list to a
+// listener therefore refused every group it did not name — including
+// secp256r1, which RFC 8446 §9.1 makes mandatory to implement, so a fully
+// conforming peer with a NIST-only policy could not complete a handshake. On
+// an SMTP listener that is not a downgrade to classical: the peer meets
+// `530 5.7.0 Must issue a STARTTLS command first` on any cleartext retry and
+// the message stays queued until it bounces.
+//
+// It also lost post-quantum coverage, which is the reverse of the intent. A
+// flat list collapses HelloRetryRequest ordering, so a peer offering
+// `X25519:X25519MLKEM768` was served X25519, where the same peer against a
+// context with NO list was pulled up to the hybrid by a retry.
+//
+// So the server form is tuples: the ACTIVE key-share preference first, then
+// these — the ECDHE curves RFC 8446 §4.2.7 registers, as a second tuple the
+// server will still accept but will spend a HelloRetryRequest to climb out of.
+// The preference stays whatever the operator configured, including a
+// `pqc.setKeyShares` that opts out of hybrids; what this adds is that a
+// listener does not refuse a conforming peer outright.
+//
+// The finite-field ffdhe* groups are absent on purpose. Refusing those on a
+// listener is a policy the framework keeps; refusing registered ECDHE curves
+// on a listener whose whole job is accepting strangers is not.
+var TLS_SERVER_FALLBACK_CURVES = Object.freeze([
+  "X25519", "X448", "secp256r1", "secp384r1", "secp521r1",
+]);
+
 // ---- RFC 8879 certificate compression ----
 // Every compression algorithm this runtime can decompress, in the order the
 // runtime reports them. Both halves of a TLS connection use the same list:
@@ -356,6 +388,7 @@ module.exports = {
   FORMAT:                 FORMAT,
   PQC_GROUPS:             PQC_GROUPS,
   TLS_GROUP_PREFERENCE:   TLS_GROUP_PREFERENCE,
+  TLS_SERVER_FALLBACK_CURVES: TLS_SERVER_FALLBACK_CURVES,
   TLS_GROUP_CURVE_STR:    TLS_GROUP_CURVE_STR,
   TLS_CERT_COMPRESSION:   TLS_CERT_COMPRESSION,
   VAULT_PREFIX:           VAULT_PREFIX,

package/lib/mail-server-tls.js

@@ -169,6 +169,14 @@ var DEFAULT_POLL_MS = C.TIME.seconds(30);
 // way to answer the question except by re-deriving the options itself — and a
 // re-derivation agrees with the build right up until someone changes one.
 //
+// The SERVER form, `b.network.tls.serverKeyAgreementGroups`, not the outbound
+// one. A flat colon list is an offer order to a client and an accept SET to a
+// server, so the client list applied here refused every group it did not name
+// — secp256r1 among them, which RFC 8446 §9.1 makes mandatory to implement —
+// and collapsed the HelloRetryRequest ordering that pulls a peer up to a
+// hybrid. The server form is tuples, which accepts every registered ECDHE
+// curve while still preferring a hybrid.
+//
 // The key-agreement preference comes from `b.network.tls.keyAgreementGroups`,
 // which is where the framework's PQC-first policy lives — the ML-KEM hybrids
 // with a classical X25519 fallback — along with the reasoning about which key
@@ -191,7 +199,7 @@ var DEFAULT_POLL_MS = C.TIME.seconds(30);
 // verification posture.
 function _contextOptions(sourceOpts, certPem, keyPem) {
   var base = { cert: certPem, key: keyPem };
-  var groups = networkTls().keyAgreementGroups(
+  var groups = networkTls().serverKeyAgreementGroups(
     sourceOpts ? sourceOpts.ecdhCurve : undefined,
     "b.mail.server.tls.context: opts.ecdhCurve");
   if (groups) base.ecdhCurve = groups;

package/lib/network-smtp-policy.js

@@ -716,7 +716,21 @@ async function tlsRptSubmit(report, opts) {
       } else if (/^mailto:/i.test(uri)) {
         // Operator-side transport. Surface the prepared body so the
         // operator can hand it to b.mail directly.
-        var mailtoTarget = uri.slice("mailto:".length);
+        var publishedTarget = uri.slice("mailto:".length);
+        // The address is published by the RECEIVING domain in its own
+        // `_smtp._tls` record. It is not operator input to this sender, and a
+        // peer spelling its hostname absolutely is using the form RFC 1035 §3.1
+        // defines — a zone file writes it that way routinely.
+        //
+        // So fold one trailing dot before validating rather than validating the
+        // spelling as published. Strictness normally protects the party doing
+        // the refusing; here it costs the OTHER party the report they asked for
+        // under RFC 8460 and costs this sender nothing — the entry silently
+        // never becomes a report. That is the direction that makes the lenient
+        // reading correct. The fold cannot turn a valid address into a
+        // different valid one, because a trailing dot is not legal in an
+        // addr-spec domain, so a name carrying one has exactly one reading.
+        var mailtoTarget = publishedTarget.replace(/\.$/, "");
         // RFC 5322 §3.4.1 addr-spec validation — refuse mailto: rua
         // entries that aren't valid addresses. Pre-v0.8.32 the
         // framework would forward whatever string came after
@@ -730,6 +744,9 @@ async function tlsRptSubmit(report, opts) {
           entry.ok = true;
           entry.mailto = {
             to:          mailtoTarget,
+            // What the peer actually published, kept beside what was used, so
+            // an operator reading the result can see the two are different.
+            published:   publishedTarget,
             subject:     "Report Domain: " + (report["organization-name"] || "") +
                          " Submitter: " + (report["organization-name"] || "") +
                          " Report-ID: <" + (report["report-id"] || "") + ">",

package/lib/network-tls.js

@@ -80,6 +80,10 @@ var STATE = {
   systemTrust:     false,
   baselineFingerprints: null,
   tlsKeyShares:    ["X25519MLKEM768", "SecP256r1MLKEM768", "SecP384r1MLKEM1024", "X25519"],
+  // False until pqc.setKeyShares is called. The list above is the shipped
+  // default, and a listener widens THAT for interoperability; a list the
+  // operator chose is taken as written.
+  tlsKeySharesConfigured: false,
 };
 
 function _normalizePem(pem) {
@@ -566,6 +570,68 @@ function keyAgreementGroups(override, where) {
   return STATE.tlsKeyShares.length > 0 ? STATE.tlsKeyShares.join(":") : null;
 }
 
+// The same policy in the shape a LISTENER needs.
+//
+// keyAgreementGroups above returns a flat colon-separated list, which is an
+// offer order on a client and an accept SET on a server — OpenSSL 3.5 reads
+// only `/`-separated tuples as an order. Handing a listener the client form
+// made it refuse every group the list did not name, secp256r1 included, and
+// collapsed the retry ordering that pulls a peer up to a hybrid. So a server
+// takes this instead, and the difference is not a detail a call site should
+// have to remember.
+//
+// An override is honoured verbatim and a malformed one refused, exactly as on
+// the client side: an operator who names their own groups gets them, and gets
+// told when what they named cannot be parsed rather than being silently given
+// the default.
+// The PREFERENCE half is whatever is active — the same STATE.tlsKeyShares the
+// client form reads, so an operator who called pqc.setKeyShares to opt out of
+// hybrids gets listeners that do not prefer them either. Hardcoding the default
+// here would have let a configured policy apply outbound and be silently
+// ignored inbound, which is worse than not having the helper.
+//
+// The fallback tuple only ADDS acceptance; it never changes what is preferred,
+// and anything already in the preference is not repeated into it.
+function serverKeyAgreementGroups(override, where) {
+  if (override !== undefined && override !== null) {
+    return _groupPreferenceString(override, where || "tls.serverKeyAgreementGroups");
+  }
+  var preferred = STATE.tlsKeyShares.length > 0
+    ? STATE.tlsKeyShares.slice()
+    : C.TLS_GROUP_PREFERENCE.slice();
+  if (preferred.length === 0) return null;
+
+  // EVERY configured rank is its own tuple, in order.
+  //
+  // Ordering exists only BETWEEN tuples: groups sharing one are a set the
+  // server takes in whatever order the handshake reaches them. So any two
+  // preferences packed into a single tuple stop being ranked — a hybrid beside
+  // X25519 loses to it whenever a peer offers both, and `["secp384r1",
+  // "X25519"]` silently negotiates X25519. One tuple per entry is the only
+  // shape that means what the configured list says.
+  //
+  // The acceptance-only curves come last, as a single tuple: they are there so
+  // a conforming peer is never refused, and carry no preference between
+  // themselves.
+  //
+  // They are added ONLY to the shipped default. An operator who called
+  // setKeyShares narrowed the policy deliberately — the module's own FIPS
+  // example drops the X25519-based groups — and adding those back would let a
+  // peer negotiate exactly what they excluded, with the restriction holding
+  // outbound and silently not holding inbound. A narrowed listener may refuse
+  // a conforming peer; that is the operator's choice to make, and it is
+  // visible, where the reverse would not be.
+  var named = preferred.map(function (g) { return String(g).toLowerCase(); });
+  var fallback = STATE.tlsKeySharesConfigured ? [] :
+    C.TLS_SERVER_FALLBACK_CURVES.filter(function (g) {
+      return named.indexOf(String(g).toLowerCase()) === -1;
+    });
+
+  var tuples = preferred.slice();
+  if (fallback.length > 0) tuples.push(fallback.join(":"));
+  return tuples.join("/");
+}
+
 function applyToContext(opts) {
   opts = opts || {};
   validateOpts(opts, ["base"], "tls.applyToContext");
@@ -699,6 +765,12 @@ function setKeyShares(list) {
   }
   for (var i = 0; i < list.length; i += 1) _validateKeyShare(list[i]);
   STATE.tlsKeyShares = list.slice();
+  // Records that this list is a CHOICE rather than the shipped default. A
+  // listener adds interoperability curves to the default so it does not refuse
+  // a conforming peer out of the box; it must not add them to a list the
+  // operator narrowed on purpose, or a restriction would hold outbound and be
+  // silently undone inbound.
+  STATE.tlsKeySharesConfigured = true;
   _postureGeneration += 1;
   return getKeyShares();
 }
@@ -707,6 +779,11 @@ function getKeyShares() { return STATE.tlsKeyShares.slice(); }
 
 function resetKeyShares() {
   STATE.tlsKeyShares = DEFAULT_PQC_KEY_SHARES.slice();
+  // Back to the shipped default in every respect, including whether a listener
+  // widens it for interoperability. Restoring the list but keeping the
+  // configured flag would leave a reset process serving a different group
+  // policy from a fresh one, which is not what a reset means.
+  STATE.tlsKeySharesConfigured = false;
   _postureGeneration += 1;
   return getKeyShares();
 }
@@ -1251,6 +1328,7 @@ function _resetForTest() {
   STATE.systemTrust = false;
   STATE.baselineFingerprints = null;
   STATE.tlsKeyShares = DEFAULT_PQC_KEY_SHARES.slice();
+  STATE.tlsKeySharesConfigured = false;
 }
 
 // ---- OCSP / OCSP-stapling wrappers around node:tls ----------------
@@ -4156,6 +4234,7 @@ module.exports = {
   detectBaselineDrift: detectBaselineDrift,
   applyToContext:      applyToContext,
   keyAgreementGroups:  keyAgreementGroups,
+  serverKeyAgreementGroups: serverKeyAgreementGroups,
   buildOptions:        buildOptions,
   getCaPems:           getCaPems,
   ocsp:                ocsp,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@blamejs/core",
-  "version": "0.18.56",
+  "version": "0.18.57",
   "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:e4edcf7d-70cf-4995-b5eb-587eff95c384",
+  "serialNumber": "urn:uuid:5ef2737c-fb9a-4fb4-b7c7-2550c5030855",
   "version": 1,
   "metadata": {
-    "timestamp": "2026-08-28T06:45:48.742Z",
+    "timestamp": "2026-08-28T08:40:52.381Z",
     "lifecycles": [
       {
         "phase": "build"
@@ -19,14 +19,14 @@
       }
     ],
     "component": {
-      "bom-ref": "@blamejs/core@0.18.56",
+      "bom-ref": "@blamejs/core@0.18.57",
       "type": "application",
       "name": "blamejs",
-      "version": "0.18.56",
+      "version": "0.18.57",
       "scope": "required",
       "author": "blamejs contributors",
       "description": "The Node framework that owns its stack.",
-      "purl": "pkg:npm/%40blamejs/core@0.18.56",
+      "purl": "pkg:npm/%40blamejs/core@0.18.57",
       "properties": [],
       "externalReferences": [
         {
@@ -54,7 +54,7 @@
   "components": [],
   "dependencies": [
     {
-      "ref": "@blamejs/core@0.18.56",
+      "ref": "@blamejs/core@0.18.57",
       "dependsOn": []
     }
   ]