ses v1.13.0

• Two new stackFiltering: options are added

  • 'omit-frames' -- Only omit likely uninteresting frames. Keep original paths.
  • 'shorten-paths' -- Only shorten paths to text likely clickable in an IDE

  This fills out the matrix of what should have been orthogonal options. The existing 'concise' setting both omits likely uninteresting frames and shortens their paths. The existing 'verbose' setting does neither.

• Uses the @endo/immutable-arraybuffer shim to add ArrayBuffer.p.immutable, ArrayBuffer.p.transferToImmutable, and ArrayBuffer.p.sliceToImmutable to ses, in order to emulate the Immutable ArrayBuffer proposal. These make an ArrayBuffer-like object whose contents cannot be mutated. However, due to limitations of the shim

  • Unlike ArrayBuffer and SharedArrayBuffer this shim's ArrayBuffer-like object cannot be transfered or cloned between JS threads.
  • Unlike ArrayBuffer and SharedArrayBuffer, this shim's ArrayBuffer-like object cannot be used as the backing store of TypeArrays or DataViews.
  • The shim depends on the platform providing either structuredClone or Array.prototype.transfer. Node <= 16 and provides neither, causing the shim to fail to initialize, and therefore SES to fail to initialize on such platforms.
  • Current Hermes has even stronger constraints, lacking structuredClone, transfer, private fields, and even class syntax. This requires other coping strategies. See feat(immutable-arraybuffer): sliceToImmutable Hermes ponyfill and shim #2785
  • Even after the upcoming transferToImmutable proposal is implemented by the platform, the current code will still replace it with the shim implementation, in accord with shim best practices. See feat(ses): ArrayBuffer.p.transferToImmutable #2311 (comment) . It will require a later manual step to delete the shim or have it avoid overriting a platform implementation, after manual analysis of the compat implications.

• The evalTaming option 'safe-eval' now can only throw error SES_DIRECT_EVAL. This allows SES to initialize with 'unsafe-eval' or 'no-eval' on hosts with no direct eval available such as Hermes for a successful lockdown that tolerates it's language features.

  The module name ses/hermes can now be required to call lockdown and repairIntrinsics only, Compartment is not yet available.

  It is currently compatible with Hermes v0.12.0, we plan to support v0.13.0 then subsequent Hermes tags or side-by-side versions built for React Native depending on ecosystem usage and official support, then Static Hermes when released.

  Also ses/hermes can now be hooked into bundlers such as Metro to run Hardened JS.

@endo/compartment-mapper v1.6.1

• The dev flag for mapNodeModules() is no longer deprecated. The concept of a "condition" (conditional exports) is disinct from the flag's original meaning (instructs mapNodeModules() to consider devDependencies when graphing packages). Users who have switched to using a development condition for dev's purpose are encouraged to switch back to using the dev flag instead. In a future release, the presence of a development condition will no longer mimic an enabled dev flag and will only be considered when evaluating conditional exports.

@endo/evasive-transform v2.0.0

• The sourceType option is now restricted to script and module only. Function signature types have changed to be more precise.

@endo/bundle-source v4.1.0

• The 'endoZipBase64' moduleFormat now utilizes the importHook option to exit dependencies whose specifiers return a truthy value.

@endo/import-bundle v1.5.0

• The 'endoZipBase64' moduleFormat now utilizes the importHook option.