ses@2.3.0

Minor Changes

• #3308 4da9a99 Thanks @kriskowal! - Drop the immutable-ArrayBuffer pseudo-prototype.

  Emulated immutable ArrayBuffers produced by @endo/immutable-arraybuffer now inherit directly from ArrayBuffer.prototype rather than from an intermediate prototype. Object.getPrototypeOf(immuAB) === ArrayBuffer.prototype for both emulated immutable and genuine buffers; the brand check is the new immutable accessor on ArrayBuffer.prototype installed by the shim.

  The [Symbol.toStringTag] slot is preserved as an own property on each emulated immutable buffer (not on the shared prototype), so Object.prototype.toString.call(immuAB) continues to return '[object ImmutableArrayBuffer]' (as in master) while genuine ArrayBuffers continue to read as '[object ArrayBuffer]'. This keeps concordance (and any other downstream consumer that sniffs the toStringTag to decide whether the value is a genuine exotic) from misrouting an emulated immutable through Node's Buffer.from, which throws because the emulated immutable is not an exotic object.

  @endo/immutable-arraybuffer is now a side-effect-only package: its sole public export is ./shim.js. The index.js and the package's . entry are removed; the previously exported names (isBufferImmutable, sliceBufferToImmutable, optTransferBufferToImmutable) are no longer reachable from outside the package. Callers detect immutability via the ArrayBuffer.prototype.immutable accessor (or Object.prototype.toString.call(buffer) === '[object ImmutableArrayBuffer]' when the shim has not been loaded) and convert via buffer.sliceToImmutable(...) and buffer.transferToImmutable(...) on the prototype. The break is a major bump for the @endo/immutable-arraybuffer package.

  @endo/bytes's to-immutable.js imports @endo/immutable-arraybuffer/shim.js (triggering the shim install) and calls buffer.sliceToImmutable(...) on ArrayBuffer.prototype instead of the previously exported sliceBufferToImmutable free function.

  The shim's install policy is now detect-then-skip rather than warn-and-overwrite: the Immutable ArrayBuffer proposal has reached stage 3, so any prior installation (native or previously loaded shim) wins. If 'sliceToImmutable' in ArrayBuffer.prototype is already true when the shim loads, the shim does nothing.

  ses drops the %ImmutableArrayBufferPrototype% permits entry, which no longer has a referent. The three permits lines inside %ArrayBufferPrototype% that declare the shim-installed methods (transferToImmutable, sliceToImmutable, immutable) stay as-is.

  @endo/pass-style's byteArray brand check no longer routes through an intermediate prototype; it consults the immutable accessor on ArrayBuffer.prototype directly. The check also tolerates the [Symbol.toStringTag] own-property on emulated immutable buffers and verifies that its value is a non-enumerable data property with a string value.

• #3322 eeefaa0 Thanks @kriskowal! - Permit TextEncoder and TextDecoder as universal intrinsics.

  TextEncoder and TextDecoder are pure transformations between string and Uint8Array with no static side channels, so they are now permitted on every compartment (start compartment and every compartment created after lockdown, identity-equal). Their prototypes are frozen alongside the other tamed primordials. On hosts that do not provide them (XS), lockdown proceeds without them and compartments observe their absence as before.

  Code that monkey-patches TextEncoder.prototype or TextDecoder.prototype after lockdown() will now throw, because the prototypes are frozen. Such mutations must happen before lockdown, the same rule that already applies to every other intrinsic.

• #3220 d47d74f Thanks @boneskull! - Exposes __noNamespaceBox__ getter on Compartment.

• #3316 71cbdb9 Thanks @boneskull! - makeError() now allows a code?: string option, which sets a code property on the resulting Error, if so desired.

Patch Changes

• #3306 a85b212 Thanks @gibson042! - - consoleTaming: 'safe' prevents Node.js console logging from invoking custom inspect methods

• #3307 c69eb03 Thanks @gibson042! - The console format specifier %c is for consuming a CSS style string and applying that style to the rendering of the remaining arguments. Node.js and browsers both parse %c the same way and have it consume one argument.

  • Browsers actually make use of the CSS, leading to security problems (e.g., https://issues.chromium.org/40056332 ).
  • Node.js ignores the %c and its corresponding argument, which is allowed by the WHATWG Console specification.

  To avoid the CSS security problems on all platforms, under the defaut consoleTaming: 'safe', we now sanitize out the %c and corresponding argument, emulating the allowed current Node.js behavior on all platforms. This fixes this CSS vulnerability while maintaining compatibility with the specification. We also treat unknown specifiers in a future-proof manner.

• #3309 bfa149b Thanks @boneskull! - makeError now narrows type of return instance when errConstructor provided.

• Updated dependencies [4da9a99]:

  • @endo/immutable-arraybuffer@2.0.0