Fail-safe for environments without unsafe-eval CSP

[mhofman]

SES relies on dynamic eval for its own initialization and virtualizing Compartment evaluators.

Some environments prevent execution of such dynamic eval, such as a browser with Content-Security-Policy not including 'unsafe-eval' in its script-src policy.

SES's initialization does some dynamic eval to tame the Function constructors. However this currently includes an idempotency test which is too lax, and fails open if 'unsafe-eval' is not allowed. Also, a dynamic eval is considered for addition to make SES more resilient against transpilers (#902).

endo/packages/ses/src/tame-function-constructors.js

Lines 46 to 53 in 1ee0a1f

	try {
	// Verify that the method is not callable.
	// eslint-disable-next-line @endo/no-polymorphic-call
	FERAL_FUNCTION.prototype.constructor('return 1');
	} catch (ignore) {
	// Throws, no need to patch.
	return {};
	}

While this is not really a security issue since the Compartment API doesn't work at all without 'unsafe-eval', changes like the one proposed in #881 are looking into using the Compartment feature without requiring dynamic eval of code. The actual taming doesn't have to rely on dynamic eval anymore than the current way anonymous intrinsics are looked up by direct syntax. For that matter, the logic for looking up the intrinsic could probably be deduplicated between repairFunction and getAnonymousIntrinsics.

It could also be argued that in an environment with no dynamic eval, the intrinsic eval and Function constructors are not feral and thus safe to leave in place. However making this behavior an explicit opt-in would be preferable, if at all allowed, instead of the current fail-open situation.