@blamejs/core 0.17.10 → 0.17.12

package/CHANGELOG.md

@@ -8,6 +8,10 @@ upgrading across more than a few patches at a time.
 
 ## v0.17.x
 
+- v0.17.12 (2026-07-22) — **The vendored Public Suffix List is refreshed to the current upstream snapshot.** The vendored Mozilla Public Suffix List is updated to the current upstream build, so organizational-domain derivation for DMARC identifier alignment, BIMI issuer scoping, cookie-scope confinement, and same-site policy reflects the current registry delegations. The data module is regenerated and re-signed across all four integrity layers, the manifest hashes are refreshed, and the NOTICE attribution date is updated. **Security:** *Public Suffix List refreshed to the current upstream snapshot* — The vendored Mozilla Public Suffix List is updated to the current upstream snapshot, so organizational-domain derivation reflects the current registry delegations everywhere the framework draws a registrable-domain boundary -- DMARC identifier alignment, BIMI issuer scoping, cookie-scope confinement, and same-site policy. The precise upstream commit and version are recorded in the signed data file and the vendor manifest. The .data.js carrier is regenerated and re-signed across all four integrity layers (SHA-256 + SHA3-512 + SLH-DSA-SHAKE-256f signature + in-payload canary), the manifest hashes are refreshed, and the NOTICE attribution date is updated.
+
+- v0.17.11 (2026-07-17) — **The DER decoder rejects a non-minimal length encoding, and the OAuth client-attestation verifier pins the JWT type so a JWT minted for another purpose can't be replayed into the attestation slot.** The shared ASN.1 DER decoder accepted a non-minimal long-form length encoding (a long form used for a value that fits the short form, or a length carrying a leading-zero octet), a BER/DER parser-differential an attacker could use to smuggle an alternate encoding of a certificate, CMS structure, or OCSP response past the strict decoder. And the OAuth client-attestation verifier did not pin the JOSE type header of the attestation and proof-of-possession JWTs, so a JWT minted for another purpose but signed by the same key could be replayed into the attestation slot. **Security:** *DER decoder rejects a non-minimal length encoding* — b.asn1Der is the shared DER reader every certificate, CMS, and OCSP parse in the framework routes through. X.690 §10.1 requires the minimum number of length octets: the long form may be used only for lengths of 128 or more, and must carry no leading-zero octet. The decoder accepted both non-minimal forms -- a long-form length for a value that fits the short form, and a long-form length with a leading zero -- which is a BER/DER parser-differential an attacker can use to encode the same structure two ways and slip an alternate encoding past a strict verifier that canonicalizes differently. The decoder already refused every other BER-ism it encounters (indefinite-length, non-minimal OID sub-identifiers, non-minimal high-tag-number tags); it now also refuses a non-minimal length, closing the remaining differential. · *OAuth client-attestation verifier pins the JWT type* — b.auth.oauth's attestation-based client authentication (draft-ietf-oauth-attestation-based-client-auth) verifies two JWTs -- the client-attestation JWT and its proof-of-possession JWT -- each of which carries a REQUIRED, distinct JOSE type header (oauth-client-attestation+jwt and oauth-client-attestation-pop+jwt). The verifier checked the signature and claims but not the type header, so a JWT minted for a different purpose but signed by the same key -- a private_key_jwt client assertion, or the other proof-of-possession JWT -- could be replayed into the attestation or PoP slot (the cross-JWT confused-deputy class RFC 8725 §3.11 explicit typing defends against). The verifier now pins the expected type for each slot, and the builders emit the same literals so a produced and a checked type can never drift; the framework's DPoP and back-channel-logout JWT verifiers already pin their type, and the attestation verifier now matches.
+
 - v0.17.10 (2026-07-17) — **A CIDR-scoped SMTP relay allowlist is now actually enforced instead of relaying for the whole internet, EU AI-Act social scoring is flagged prohibited for any actor rather than only public authorities, and the X-Wing hybrid KEM stays uniform implicit-rejection on a low-order X25519 point.** The mail server's relay authorization discarded its arguments and returned allowed for every connecting peer whenever an operator configured any relayAllowedFor entry, so a per-CIDR relay allowlist -- intended to scope relay to registered sources -- turned the server into an open relay for the entire internet. The EU AI-Act prohibited-practice classifier gated social scoring on the deployer being a public authority, a limitation that was in the 2021 Commission proposal but dropped from the adopted Regulation (EU) 2024/1689, so a private-actor social-scoring system was under-classified as not-prohibited. The GDPR record-of-processing updater validated a legal-basis change with a truthiness guard, so a falsy-but-invalid value skipped the enum check and could corrupt a required Article 30 field. And the X-Wing hybrid post-quantum KEM threw a raw derivation error on a low-order X25519 point instead of the uniform implicit-rejection its contract and the draft specification require, exposing a decapsulation-oracle distinguisher and a crash for any consumer following the documented no-try/catch advice. **Security:** *SMTP relay allowlist enforces its per-entry CIDR instead of relaying for everyone* — b.mail.server.mx accepts a relayAllowedFor allowlist of { cidr, scope } entries, documented as scoping relay to registered source ranges over the default MX-only, no-relay posture. The relay-authorization check discarded both the peer address and recipient and simply returned allowed whenever the allowlist was non-empty, so an operator restricting relay to, for example, 10.0.0.0/8 actually granted relay to every peer on the internet -- an open relay, directly contradicting the module's advertised open-relay defense. The check now admits relay only when the connecting peer's source address falls inside one of the allowlisted ranges (using the same range arithmetic the HTTP network-allowlist fence uses); a peer outside every range is refused. Each relayAllowedFor entry's cidr is now validated at startup -- a mask is required so a bare IP cannot silently disable an entry, private and reserved ranges are allowed since relay allowlists legitimately name them, and a malformed entry throws at boot rather than mis-scoping relay. · *AI-Act classifier flags social scoring by any actor as prohibited* — b.compliance.aiAct's prohibited-practice classifier implements EU AI-Act Article 5. Its social-scoring gate (Art. 5(1)(c)) required both the purpose to be social scoring and the deployer to be a public authority before flagging the practice as prohibited. The "by public authorities or on their behalf" limitation existed in the 2021 Commission proposal but was removed from the adopted Regulation (EU) 2024/1689, which prohibits social scoring by any actor. A private-actor social-scoring system was therefore under-classified as not-prohibited. The classifier now flags social scoring on the purpose alone, matching the adopted text; the other Article 5 gates (predictive policing based solely on profiling, untargeted facial-recognition scraping, emotion inference in the workplace/education outside medical/safety uses) correctly retain the conjuncts that are part of their statutory definitions rather than over-broad limitations. · *GDPR record-of-processing rejects a falsy-but-invalid legal basis on update* — b.gdpr.ropa records the Article 30 register of processing activities, whose legalBasis field is constrained to the six Article 6(1) bases. register validates the basis against the allowlist, but update validated a legal-basis change with a truthiness guard, so a falsy-but-invalid value (an empty string, and similar) short-circuited past the enum check and was written into the record -- silently corrupting a required Article 30 field. The updater now validates whenever the patch touches legalBasis, keyed on the field being present rather than truthy, so an invalid value is rejected with the same rigor register applies and a genuine change to a valid basis still succeeds. · *X-Wing hybrid KEM stays uniform implicit-rejection on a low-order X25519 point* — b.crypto.xwing implements the X-Wing hybrid post-quantum KEM (ML-KEM-768 combined with X25519), whose contract and the draft-connolly-cfrg-xwing-kem specification require decapsulation to be uniform implicit-rejection: a tampered ciphertext yields a different secret, never an error, so a consumer must not branch on success. But a hostile low-order X25519 point in the ciphertext (or in the recipient's X25519 public half) drove the X25519 derivation to an all-zero shared secret, which the underlying library aborts with a raw derivation error rather than returning the value RFC 7748 X25519 (without the optional abort) yields. That exposed a decapsulation-oracle distinguisher (a low-order point throws while every other ciphertext returns a secret) and a crash for any caller following the documented advice not to wrap decapsulation in a try/catch. The shared X25519 step now translates that abort back into the all-zero shared secret, restoring uniform implicit-rejection; the combiner still binds the X25519 ciphertext and public key and the ML-KEM-768 leg still protects the result, so the hybrid's secure-if-either-holds guarantee is unchanged.
 
 - v0.17.9 (2026-07-17) — **A prototype-member regime name no longer voids a breach-notification clock into reporting a missed deadline as met, a planted plaintext file can no longer stand in for the sealed keyed-hash MAC key, and content-safety sanitization recomputes the integrity descriptor over the bytes actually delivered.** The incident-report deadline clock resolved its per-regime statutory table by a plain-object lookup with no own-property check, so a regime name equal to an inherited object member (valueOf, toString, constructor) resolved to a prototype function instead of the default deadlines -- every due-by became NaN, and a notification filed long past a statutory wall was recorded on-time, reporting a missed regulatory deadline as met. The retention posture-floor lookup had the same defect. The vault's keyed-hash MAC key reader trusted the vault's documented pass-through of a non-sealed value, so a plaintext file substituted on disk was accepted as the secret MAC key without the vault passphrase. And the static file server and the upload finalizer both replaced the served/stored payload when a content-safety gate sanitized it but kept advertising the ORIGINAL bytes' ETag/SRI (static) and sha3/size descriptor (upload), so a client validating the integrity of the delivered body -- or an operator storing the reported hash as the dedup/integrity key -- got a digest that did not match what was actually delivered. **Security:** *Breach-notification and retention lookups reject a prototype-member name* — b.incident.report's deadline clock resolves the statutory deadline set for an incident's regime (GDPR 72h, NIS2 24h, DORA 4h initial, HIPAA 60 days, ...) by indexing a per-regime table with the operator-supplied regime string. The lookup used a truthiness check with no own-property guard, so a regime equal to an inherited object member -- valueOf, toString, constructor, hasOwnProperty -- resolved to the prototype function instead of falling back to the default deadlines. Every computed due-by then became NaN, and because a late comparison against NaN is never true, a notification filed long past the real statutory wall was recorded on-time (not late) and the clock's late count stayed zero -- a genuinely missed regulatory deadline reported to a regulator as met. b.retention's compliance-posture floor lookup (hipaa, pci-dss, gdpr, soc2) had the identical defect, resolving a prototype-member posture to an inherited function as the retention floor. Both now resolve the name through an own-property check, so a prototype-member name falls back to the default deadlines (incident-report) or is rejected as an unknown posture (retention); real regimes and postures are unaffected. · *Vault refuses a non-sealed file as the keyed-hash MAC key* — b.vault derives a keyed-hash MAC key (used by field-level encryption's keyed derived-hash mode to keep an attacker with disk access from correlating low-entropy plaintexts) and seals it at rest. The reader loaded the sealed file and called the vault's unseal, which by its documented idempotent-read contract returns any value lacking the vault seal prefix verbatim -- so a plaintext 32-byte value planted on disk passed straight through and was accepted as the MAC key. In wrapped-vault mode this let an attacker with disk-write access but no vault passphrase (and therefore unable to forge a genuine seal) inject a known MAC key, downgrading the keyed derived-hash to an attacker-known key. The reader now requires the on-disk value to actually be sealed (carry the vault prefix) before unsealing, refusing a substituted plaintext or otherwise-unsealed file -- the same load-bearing prefix check the database key loader and the key-rotation pipeline already apply to their sealed key material. · *Content-safety sanitization recomputes the served body's integrity descriptor* — When a content-safety gate returns a sanitize action it replaces the payload with the cleaned bytes. b.staticServe still emitted the strong ETag and subresource-integrity (SRI) header derived from the original file on disk, and b.fileUpload's finalizer still handed onFinalize (and recorded in the audit) the sha3 and size of the original assembled bytes -- so the integrity descriptor advertised for the delivered/stored bytes did not match them. A browser performing SRI verification of the sanitized static response would fail the check, a strong-validator or If-None-Match cache would be keyed to a representation the client never receives, and an operator storing the upload's reported sha3 as the integrity or dedup key of the stored (sanitized) file would record a hash that never matches it. Both now recompute the ETag/SRI (static) and the sha3/size descriptor (upload) over the bytes actually delivered whenever a gate sanitized the payload; an unsanitized response keeps the on-disk/reassembly digest, which already describes the delivered bytes.

package/NOTICE

@@ -90,7 +90,7 @@ Used for:    Top-10000 most-common (breach-derived) passwords. Loaded by
              baseline.
 --------------------------------------------------------------------------------
 Component:   publicsuffix-list (Mozilla Public Suffix List)
-Version:     master snapshot (bundled 2026-07-15)
+Version:     master snapshot (bundled 2026-07-22)
 Source:      https://publicsuffix.org/list/public_suffix_list.dat
 License:     MPL-2.0
 Copyright:   Copyright (c) Mozilla Foundation and Public Suffix List contributors

package/lib/asn1-der.js

@@ -132,6 +132,18 @@ function readNode(buf, offset) {
     for (var i = 0; i < lenOctets; i += 1) {
       length = (length * 256) + buf[offset + headerLen + i];                    // base-256 length bytes
     }
+    // X.690 §10.1: DER requires the MINIMUM number of length octets. Long
+    // form is only permitted for lengths >= 128, and must carry no leading-
+    // zero octet — reject both non-minimal forms so an attacker-supplied
+    // certificate / CMS / OCSP response cannot smuggle a BER/DER parser-
+    // differential encoding through the shared walker. The decoder already
+    // refuses every other BER-ism (indefinite length, non-minimal OID
+    // subidentifiers, non-minimal high-tag-number tags); enforcing minimal
+    // lengths closes the remaining gap.
+    if (length < 128 || buf[offset + headerLen] === 0) {                        // X.690 §10.1 short-form boundary / no leading-zero octet
+      throw new Asn1Error("asn1/length-non-minimal",
+        "long-form length is not DER-minimal (length=" + length + ")");
+    }
     headerLen += lenOctets;
   }
 

package/lib/auth/oauth.js

@@ -512,6 +512,13 @@ var ATTESTATION_ALGS = Object.freeze([
   "EdDSA",
 ]);
 
+// draft-ietf-oauth-attestation-based-client-auth §4.1 / §5.1 — the REQUIRED,
+// distinct `typ` header of each JWT. One literal per role, used by BOTH the
+// builders (the value we emit) and the verifier (the value we pin) so the
+// produced typ and the checked typ can never drift apart.
+var ATTESTATION_JWT_TYP     = "oauth-client-attestation+jwt";
+var ATTESTATION_POP_JWT_TYP = "oauth-client-attestation-pop+jwt";
+
 // Cap on an attestation / PoP JWT. HTTP-header-borne JWTs are small;
 // 16 KiB refuses a pathological header without touching real tokens.
 var MAX_ATTESTATION_JWT_BYTES = C.BYTES.kib(16);
@@ -582,7 +589,10 @@ function _signAttestationJws(header, payload, privateKey, alg) {
 // Verify a compact JWS against an already-imported public KeyObject. The
 // alg is read from the header but MUST equal expectedAlg AND match the
 // key's kty (via the shared cross-check) — no alg-confusion window.
-function _verifyAttestationJws(jws, publicKeyJwk, label) {
+// `expectedTyp` (when supplied) pins the JOSE `typ` header so a JWT minted
+// for another purpose but signed by the same key can't be replayed into the
+// attestation / PoP slot.
+function _verifyAttestationJws(jws, publicKeyJwk, label, expectedTyp) {
   if (typeof jws !== "string" || jws.length === 0) {
     throw new OAuthError("auth-oauth/attestation-malformed", label + ": JWT must be a non-empty string");
   }
@@ -618,6 +628,18 @@ function _verifyAttestationJws(jws, publicKeyJwk, label) {
     throw new OAuthError("auth-oauth/attestation-crit-not-supported",
       label + ": JWS 'crit' header is not supported (RFC 7515 §4.1.11)");
   }
+  // Explicit typing (RFC 8725 §3.11 / draft-ietf-oauth-attestation-based-
+  // client-auth §6): the attestation and PoP JWTs each carry a REQUIRED,
+  // distinct `typ`. Pinning it stops a JWT minted for a different purpose
+  // but signed by the same key (a private_key_jwt client assertion, another
+  // proof-of-possession JWT) from being replayed into the attestation / PoP
+  // slot — the cross-JWT confused-deputy class. The framework's other JWS
+  // verifiers already pin typ (dpop+jwt, logout+jwt); this one now matches.
+  if (typeof expectedTyp === "string" && header.typ !== expectedTyp) {
+    throw new OAuthError("auth-oauth/attestation-wrong-typ",
+      label + ": header.typ must be '" + expectedTyp + "' (RFC 8725 §3.11 " +
+      "explicit typing); got " + JSON.stringify(header.typ));
+  }
   // CVE-2026-22817 — cross-check alg against the key's kty before verify.
   jwtExternal._assertAlgKtyMatch(header.alg, publicKeyJwk);
   var keyObject = _jwkToKey(publicKeyJwk);
@@ -744,7 +766,7 @@ function buildClientAttestation(aopts) {
     validateOpts.assignOwnEnumerable(payload, aopts.extraClaims, Object.keys(payload));
   }
   return _signAttestationJws(
-    { typ: "oauth-client-attestation+jwt", alg: alg }, payload, key, alg);
+    { typ: ATTESTATION_JWT_TYP, alg: alg }, payload, key, alg);
 }
 
 /**
@@ -819,7 +841,7 @@ function buildClientAttestationPop(popts) {
     payload.challenge = popts.challenge; // draft §5.2 — server nonce
   }
   return _signAttestationJws(
-    { typ: "oauth-client-attestation-pop+jwt", alg: alg }, payload, key, alg);
+    { typ: ATTESTATION_POP_JWT_TYP, alg: alg }, payload, key, alg);
 }
 
 /**
@@ -878,7 +900,8 @@ async function verifyClientAttestation(attestationJwt, popJwt, vopts) {
     "auth-oauth/attestation-no-expected-aud");
 
   // 1. Attestation signature against the TRUSTED attester key.
-  var att = _verifyAttestationJws(attestationJwt, vopts.attesterJwk, "client-attestation");
+  var att = _verifyAttestationJws(attestationJwt, vopts.attesterJwk, "client-attestation",
+    ATTESTATION_JWT_TYP);
   var ap = att.payload || {};
   if (typeof ap.sub !== "string" || ap.sub.length === 0) {
     throw new OAuthError("auth-oauth/attestation-no-sub",
@@ -912,7 +935,8 @@ async function verifyClientAttestation(attestationJwt, popJwt, vopts) {
   }
 
   // 2. PoP signature against the attestation's cnf key (NOT the attester).
-  var pop = _verifyAttestationJws(popJwt, ap.cnf.jwk, "client-attestation-pop");
+  var pop = _verifyAttestationJws(popJwt, ap.cnf.jwk, "client-attestation-pop",
+    ATTESTATION_POP_JWT_TYP);
   var pp = pop.payload || {};
   // aud MUST be THIS AS issuer (constant-time, exact). Attacker-replayed
   // PoP minted for a different AS is refused (draft §8 step 7).
@@ -1756,20 +1780,43 @@ function create(opts) {
 
   async function _normalizeTokens(raw, vopts) {
     vopts = vopts || {};
+    // RFC 6749 §3.3 — scope is space-separated, ONLY U+0020. `\s+` previously
+    // matched U+0085 NEL, U+00A0 NBSP, etc., so a hostile AS returning
+    // `scope: "admin<NEL>read"` would surface as `["admin", "read"]` and the
+    // operator's scope allowlist saw two distinct scopes. Spec-strict split on
+    // single-space keeps a non-token separator inside one token.
+    //
+    // §5.1 also fixes the PRESENT-vs-ABSENT distinction that a bare truthiness
+    // test lost: an ABSENT scope ("OPTIONAL, if identical to the requested
+    // scope") means the client got what it asked for → mirror the request; a
+    // PRESENT scope is authoritative, INCLUDING the empty string, which grants
+    // ZERO scopes. Coercing "" to the requested set (its falsy value slipped
+    // the old `raw.scope ? …` test into the absent branch) would report a
+    // downscoped-to-nothing grant as the full requested set — a scope-based
+    // authorization guard downstream then treats denied scopes as granted. A
+    // malformed non-string scope is treated as zero (fail closed), never as
+    // the requested set.
+    var grantedScope;
+    if (typeof raw.scope === "string") {
+      grantedScope = raw.scope.split(" ").filter(function (s) { return s.length > 0; });
+    } else if (raw.scope === undefined) {
+      // ONLY a truly ABSENT property (undefined) mirrors the request (RFC 6749
+      // §3.3 "OPTIONAL, if identical to the requested scope"). A PRESENT but
+      // malformed value — `null`, a number, an object — is NOT an omitted
+      // scope; treating `{ "scope": null }` as absent would copy the full
+      // requested set and report a grant the AS never made. Fall through to
+      // zero (fail closed).
+      grantedScope = scope.slice();
+    } else {
+      grantedScope = [];
+    }
     var tokens = {
       accessToken:  raw.access_token,
       tokenType:    raw.token_type || "Bearer",
       expiresIn:    raw.expires_in || null,
       refreshToken: raw.refresh_token || null,
       idToken:      raw.id_token || null,
-      // RFC 6749 §3.3 — scope is space-separated, ONLY U+0020.
-      // `\s+` previously matched U+0085 NEL, U+00A0 NBSP, etc., so a
-      // hostile AS returning `scope: "admin<NEL>read"` would
-      // surface as `["admin", "read"]` and the operator's scope
-      // allowlist saw two distinct scopes. Spec-strict split on
-      // single-space + reject scope tokens that contain non-token
-      // chars.
-      scope:        raw.scope ? raw.scope.split(" ").filter(function (s) { return s.length > 0; }) : scope.slice(),
+      scope:        grantedScope,
       raw:          raw,
     };
     if (tokens.idToken && isOidc) {

package/lib/vendor/MANIFEST.json

@@ -18,7 +18,7 @@
       "hashes": {
         "server": "sha256:2b30a26f728c5349f4c4b47834f862a4f77393b1224fc12b22abe3ce2cfab78f"
       },
-      "refreshedAt": "2026-07-16T01:51:24.609Z"
+      "refreshedAt": "2026-07-23T03:16:00.999Z"
     },
     "@noble/curves": {
       "version": "2.2.0",
@@ -40,7 +40,7 @@
       "hashes": {
         "server": "sha256:2880c288b1285ef51d356d057bee6f0c8a00de36638cf47b47617e8c1faf10d5"
       },
-      "refreshedAt": "2026-07-16T01:51:24.609Z"
+      "refreshedAt": "2026-07-23T03:16:00.999Z"
     },
     "@noble/post-quantum": {
       "version": "0.6.1",
@@ -71,7 +71,7 @@
       "hashes": {
         "server": "sha256:f9c94094b3c10fe73dac5343289da582454ea6053494fab2bf66099d9103d6c3"
       },
-      "refreshedAt": "2026-07-16T01:51:24.609Z"
+      "refreshedAt": "2026-07-23T03:16:00.999Z"
     },
     "@simplewebauthn/server": {
       "version": "13.3.2",
@@ -94,7 +94,7 @@
       "hashes": {
         "server": "sha256:e83195dc9f189385da9c856ef38843f4466f93ea8f3d7fc2efcb1e1b18da6f20"
       },
-      "refreshedAt": "2026-07-16T01:51:24.609Z"
+      "refreshedAt": "2026-07-23T03:16:00.999Z"
     },
     "SecLists-common-passwords-top-10000": {
       "version": "10k-most-common (master)",
@@ -114,7 +114,7 @@
       },
       "runtime_artifact": "lib/vendor/common-passwords-top-10000.data.js",
       "integrity_layers": "sha256 + sha3-512 + SLH-DSA-SHAKE-256f signature + in-payload canary (where applicable)",
-      "refreshedAt": "2026-07-16T01:51:24.609Z"
+      "refreshedAt": "2026-07-23T03:16:00.999Z"
     },
     "bimi-trust-anchors": {
       "version": "operator-managed",
@@ -139,7 +139,7 @@
       },
       "runtime_artifact": "lib/vendor/bimi-trust-anchors.data.js",
       "integrity_layers": "sha256 + sha3-512 + SLH-DSA-SHAKE-256f signature + in-payload canary (where applicable)",
-      "refreshedAt": "2026-07-16T01:51:24.609Z"
+      "refreshedAt": "2026-07-23T03:16:00.999Z"
     },
     "publicsuffix-list": {
       "version": "master",
@@ -152,14 +152,14 @@
         "data_js": "lib/vendor/public-suffix-list.data.js"
       },
       "bundler": "curl https://publicsuffix.org/list/public_suffix_list.dat",
-      "bundledAt": "2026-07-15T00:00:00Z",
+      "bundledAt": "2026-07-22T00:00:00Z",
       "hashes": {
-        "server": "sha256:57323947e6a49f93c98cf417bc8dabbc99833d548add7b4fb1528382d2469c2b",
-        "data_js": "sha256:e3ab29993abf04b4a89c2ad55fa7057c234076fb078a32daecf05d3f8ed379eb"
+        "server": "sha256:239445596e15e13c345bab8f5118a617ae3e61e4e1df437728c14cbf4aaef716",
+        "data_js": "sha256:0742bf237375961822070329cda24c866afd3c711262fafa748a40443ec18a6e"
       },
       "runtime_artifact": "lib/vendor/public-suffix-list.data.js",
       "integrity_layers": "sha256 + sha3-512 + SLH-DSA-SHAKE-256f signature + in-payload canary (where applicable)",
-      "refreshedAt": "2026-07-16T01:51:24.609Z"
+      "refreshedAt": "2026-07-23T03:16:00.999Z"
     },
     "peculiar-pki": {
       "version": "2.0.0+pkijs-3.4.0",
@@ -190,7 +190,7 @@
       "hashes": {
         "server": "sha256:2307ef65e070757ffb13442b377e45efb9fa1a10432d9b39618387720ab990ed"
       },
-      "refreshedAt": "2026-07-16T01:51:24.609Z"
+      "refreshedAt": "2026-07-23T03:16:00.999Z"
     }
   }
 }

package/lib/vendor/public-suffix-list.dat

@@ -5,8 +5,8 @@
 // Please pull this list from, and only from https://publicsuffix.org/list/public_suffix_list.dat,
 // rather than any other VCS sites. Pulling from any other URL is not guaranteed to be supported.
 
-// VERSION: 2026-07-15_18-13-59_UTC
-// COMMIT: 9b5c814414374aa19a93dc6dd7e47c01909524cc
+// VERSION: 2026-07-22_17-32-17_UTC
+// COMMIT: 8ab4253fd2cbaf4c411bd7ccea56bff0db0e82cf
 
 // Instructions on pulling and using this list can be found at https://publicsuffix.org/list/.
 
@@ -1631,7 +1631,6 @@ trentin-sudtirol.it
 trentin-südtirol.it
 trentin-sued-tirol.it
 trentin-suedtirol.it
-trentino.it
 trentino-a-adige.it
 trentino-aadige.it
 trentino-alto-adige.it
@@ -1652,7 +1651,6 @@ trentinos-tirol.it
 trentinostirol.it
 trentinosud-tirol.it
 trentinosüd-tirol.it
-trentinosudtirol.it
 trentinosüdtirol.it
 trentinosued-tirol.it
 trentinosuedtirol.it
@@ -1668,7 +1666,6 @@ umbria.it
 val-d-aosta.it
 val-daosta.it
 vald-aosta.it
-valdaosta.it
 valle-aosta.it
 valle-d-aosta.it
 valle-daosta.it
@@ -1705,7 +1702,6 @@ aosta.it
 aoste.it
 ap.it
 aq.it
-aquila.it
 ar.it
 arezzo.it
 ascoli-piceno.it
@@ -1929,6 +1925,9 @@ sondrio.it
 sp.it
 sr.it
 ss.it
+su.it
+sud-sardegna.it
+sudsardegna.it
 südtirol.it
 suedtirol.it
 sv.it
@@ -1949,6 +1948,7 @@ trani-barletta-andria.it
 traniandriabarletta.it
 tranibarlettaandria.it
 trapani.it
+trentino.it
 trento.it
 treviso.it
 trieste.it
@@ -1967,6 +1967,7 @@ ve.it
 venezia.it
 venice.it
 verbania.it
+verbano-cusio-ossola.it
 vercelli.it
 verona.it
 vi.it
@@ -12576,12 +12577,6 @@ bubbleapps.io
 // Submitted by Klara Mall <dns@bwcloud-os.de>
 *.bwcloud-os-instance.de
 
-// Bytemark Hosting : https://www.bytemark.co.uk
-// Submitted by Paul Cammish <paul.cammish@bytemark.co.uk>
-uk0.bigv.io
-dh.bytemark.co.uk
-vm.bytemark.co.uk
-
 // Caf.js Labs LLC : https://www.cafjs.com
 // Submitted by Antonio Lain <antlai@cafjs.com>
 cafjs.com
@@ -12841,10 +12836,6 @@ craft.me
 // Submitted by Ales Krajnik <ales.krajnik@craynic.com>
 realm.cz
 
-// Cryptonomic : https://cryptonomic.net/
-// Submitted by Andrew Cady <public-suffix-list@cryptonomic.net>
-*.cryptonomic.net
-
 // cyber_Folks S.A. : https://cyberfolks.pl
 // Submitted by Bartlomiej Kida <security@cyberfolks.pl>
 cfolks.pl
@@ -13511,10 +13502,6 @@ on.expo.app
 staging.expo.app
 on.staging.expo.app
 
-// Fabrica Technologies, Inc. : https://www.fabrica.dev/
-// Submitted by Eric Jiang <eric@fabrica.dev>
-onfabrica.com
-
 // fachschaften.org: https://fachschaften.org/
 // Submitted by Felix Schäfer <security@fachschaften.org>
 fspages.org
@@ -15267,10 +15254,6 @@ vki.kr
 // Submitted by yumenewa <admin@project-study.com>
 dev.project-study.com
 
-// Protonet GmbH : http://protonet.io
-// Submitted by Martin Meier <admin@protonet.io>
-protonet.io
-
 // PSL Sandbox : https://github.com/groundcat/PSL-Sandbox
 // Submitted by groundcat <psl-sandbox@alumni.upenn.edu>
 platter-app.dev
@@ -15452,10 +15435,6 @@ repl.run
 resindevice.io
 devices.resinstaging.io
 
-// RethinkDB : https://www.rethinkdb.com/
-// Submitted by Chris Kastorff <info@rethinkdb.com>
-hzc.io
-
 // Rico Developments Limited : https://adimo.co
 // Submitted by Colin Brown <hello@adimo.co>
 adimo.co.uk
@@ -15878,10 +15857,6 @@ indevs.in
 musician.io
 novecore.site
 
-// Standard Library : https://stdlib.com
-// Submitted by Jacob Lee <jacob@stdlib.com>
-api.stdlib.com
-
 // statichost.eu : https://www.statichost.eu
 // Submitted by Eric Selin <admin@statichost.eu>
 statichost.page
@@ -15908,10 +15883,6 @@ ipfs.w3s.link
 // Submitted by Tony Schirmer <tony@storebase.io>
 storebase.store
 
-// Storj Labs Inc. : https://storj.io/
-// Submitted by Philip Hutchins <hostmaster@storj.io>
-storj.farm
-
 // Strapi : https://strapi.io/
 // Submitted by Florent Baldino <security@strapi.io>
 strapiapp.com