Repair some builtin prototypes in order to tolerate the "override mistake"

[warner]

We omitted the tamperProof.js file (to fix the override mistake) when we built SES out of Realms instead of FrozenRealms, we need to pull that in.

[erights]

At https://github.com/Agoric/SES/blob/master/src/index.js there is a commented out call to tamperProofDataProperties but the only thing I could find is https://github.com/tc39/proposal-frozen-realms/blob/master/shim/src/mutable.js which is to a much earlier version. Where is the code containing the tamperProofDataProperties we used to call?

[erights]

@bmeck @littledan , where is a good place to track this issue? Could you reply with a link? Thanks.

[erights]

Sorry. By "this issue" I mean the attempt to fix the override mistake in the EcmaScript spec, which is only distantly related to this issue. Nevertheless, it would be nice to have a link here. Thanks.

[bmeck]

tc39/ecma262#1320 is probably the best place currently as it deals w/ the spec changes 1307 can probably closed in lieu of it.

[erights]

Hi @jfparadis , did you say that your data suggested we only need this repair on
Object.prototype, Function.prototype, RegExpr.prototype? What about Array.prototype`? Others?

For the prototypes we do repair, which properties should we repair?

[jfparadis]

Here is the current list:
Object.prototype
Array.prototype
Function.prototype
Error.prototype

[erights]

Thanks.

Do you have any data on which properties on these prototypes could remain unrepaired?

[jfparadis]

All prototype properties of Object and Array need to me repaired because arrays are often used as objects, and any property can be set on objects to allow compatibility.

For the rest, we can only repair Function 'name' and Error 'message'.

[kumavis]

found tamperProofDataProperties

• first as tamper-proof.js https://github.com/tc39/proposal-ses/commits/master/shim/src/tamper-proof.js
• then renamed shim/src/tamper-proof.js → shim/src/mutable.js which is as markm posted above saying it was a "much earlier version"

After finding the history, I think mutable.js is actually the newer version.

[erights]

After finding the history, I think mutable.js is actually the newer version.

Newer than tamper-proof.js, yes. But not the newest. Waiting from responses from @caridy @jdalton @jfparadis @guybedford @bmeck

[bmeck]

node is currently using https://github.com/nodejs/node/blob/554ffa34320ebfe62e6eefd4607483866362efd3/lib/internal/freeze_intrinsics.js#L253 but can align with w/e is preferred.

[erights]

I like the name enableDerivedOverride. Anyone see what the other differences are?

[manuel-jasso]

After finding the history, I think mutable.js is actually the newer version.

Newer than tamper-proof.js, yes. But not the newest. Waiting from responses from @caridy @jdalton @jfparadis @guybedford @bmeck

@erights Commenting as requested by @caridy - Salesforce's Locker uses a customized version of mutable.js, with some prototypes commented out:

    [
      i.ObjectPrototype,
      i.ArrayPrototype
      // i.BooleanPrototype,
      // i.DatePrototype,
      // i.NumberPrototype,
      // i.StringPrototype,

      // i.IteratorPrototype,
      // i.ArrayIteratorPrototype,

      // i.PromisePrototype,
      // i.DataViewPrototype,

      // i.TypedArray,
      // i.Int8ArrayPrototype,
      // i.Int16ArrayPrototype,
      // i.Int32ArrayPrototype,
      // i.Uint8Array,
      // i.Uint16Array,
      // i.Uint32Array
    ],

For these prototypes we apply beMutable to the name property only:

    [
      i.FunctionPrototype,
      i.GeneratorPrototype,
      i.AsyncFunctionPrototype,
      i.AsyncGeneratorPrototype
    ],

And for these prototypes we apply beMutable to the message property only:

    [
      i.ErrorPrototype,
      i.EvalErrorPrototype,
      i.RangeErrorPrototype,
      i.ReferenceErrorPrototype,
      i.SyntaxErrorPrototype,
      i.TypeErrorPrototype,
      i.URIErrorPrototype
    ],