feat(harden): Introduce @endo/harden

[kriskowal]

Closes: #2978

Description

This change introduces an @endo/harden package that allows packages to be written for use in a JS or a HardenedJS environment without modification. The @endo/harden module provides a behavior that depends on the environment and packaging conditions.

Without any packaging conditions, in a HardenedJS environment, @endo/harden provides the environment’s “volume freezing” harden, meaning that it freezes the closure over both dimensions: transitive properties and prototypes.

Also without any packaging conditions, if the environment does not provide a harden, @endo/harden provides a “surface freezing” harden, meaning that it freezes the closure over only the one dimension: properties. This provides a modicum of immutability without interfering with shims or other mutations to shared, intrinsic prototypes.

With the hardened condition (node -C hardened, bundle-source -C hardened), @endo/harden will not retain an implementation of harden and will assert that harden existed as Object[Symbol.for('harden')] or globalThis.harden in the environment and vend out that harden. This is useful to minimize the size of bundles that can safely presume that they will run in a HardenedJS environment.

With the noop-harden condition (node -C noop-harden), @endo/harden will provide a version of harden that returns its argument unaltered.

With these new modes, we expect to deprecate the lockdown option for "unsafe" hardenTaming which goes further and replaces isExtensible, isFrozen, and isSealed with versions that misreport true for extensible, unfrozen, or unsealed objects respectively. We hope that the new default behavior of surface hardening will suffice, but we leave the noop-harden condition as an option since that should have performance parity with unsafe harden taming for environments that need it.

As a side-effect, every kind of harden will install itself on first use at Object[Symbol.for('harden')] as a non-configurable property such that the first @endo/harden implementation used wins the race to define the hardening behavior of the realm. SES will install the same property at time of lockdown, but if it loses the race, will throw an exception indicating that the realm cannot be locked down because of unsafe usage of harden before lockdown, and render up the stack of the first use for diagnostic purposes.

Security Considerations

The @endo/harden provides a new mode of usage that is less safe than lockdown for environments in which lockdown is not practical. We do not expect safety to regress in lockdown environments as a consequence.

This change strengthens one safety guarantee: going forward, hardened modules using @endo/harden will not be vulnerable to hosts that endow a compartment with a weakened version of harden, because @endo/harden always favors the Object[Symbol.for('harden')] enshrined on a shared intrinsic hardened by lockdown.

Scaling Considerations

Adopting @endo/harden will increase the size of bundles, and since this change adopts @endo/harden throughout the Endo stack, this bundle size increase may become problematic for systems close to their bundle size limits. We provide the bundler condition hardened to mitigate this problem.

Documentation Considerations

• This change comes with documentation in README and NEWS for all impacted packages, including advice to adopt the hardened bundle condition to mitigate the bundle size increase.

Testing Considerations

This change adds configurations to sesAvaConfigs where adopting @endo/harden allows those packages to be used in more configurations. The salient configuration Endo with shims installed only, without calling Lockdown, in the cases where packages continue to rely on Assert or Eventual Send. We hope in time to test in the Base configuration, without any shims. Some packages are able to adopt the No-op mode of harden and are accordingly tested in that mode.

Compatibility Considerations

This change is additive apart from the expected increase in bundle size, for which we provide a mitigation.

Upgrade Considerations

None.