1221 was supposed to make ses tolerate undeletable func.prototype properties that should be absent, so long as they could be set to undefined instead, making them harmless. This tolerance came with a warning to flag the remaining non-conformance.
However #2598 explains why #1221 sometimes fails to do this. #1221 did come with a test, but it fell into the case where #1221 works, which is a non-toplevel function.
2563 (and #2334 ?) fell into the trap explained by #2598 and untested by #1221, which is an undeletable func.prototype on a top-level instrinsic. As a result, #2563 currently contains a workaround for #2598 which this PR would make unnecessary.
This PR fixes the problem by factoring out the func.prototype-tolerant property deletion into a separate cauterizeProperty function which it calls from both places. This PR also adds the test that was missing from #1221 , having first checked that the test detects #2598 when run without the rest of this PR.
If this PR gets merged before #2563, then #2563's workaround for #2598 can first be removed before it is merged.
[ ] TODO should pass a genuine reporter in to all calls to cauterizeProperty. @kriskowal , please advise how intrinsics.js should arrange to do so.
Security Considerations
Allowing a func.prototype property that really shouldn't be there seems safe, so long as it is safely set to undefined first, which this PR does, and then checks that it has done so.
Scaling Considerations
none
Documentation Considerations
generally, this would be one less thing to worry about, and thus one less thing that needs to be documented for most users.
Testing Considerations
Adds the test that was missing from #1221 that let #2598 go unnoticed until #2563
Closes: #2598 Refs: https://github.com/endojs/endo/pull/2563 https://github.com/endojs/endo/pull/2334 https://github.com/endojs/endo/pull/1221
Description
1221 was supposed to make ses tolerate undeletable
func.prototypeproperties that should be absent, so long as they could be set toundefinedinstead, making them harmless. This tolerance came with a warning to flag the remaining non-conformance.However #2598 explains why #1221 sometimes fails to do this. #1221 did come with a test, but it fell into the case where #1221 works, which is a non-toplevel function.
2563 (and #2334 ?) fell into the trap explained by #2598 and untested by #1221, which is an undeletable
func.prototypeon a top-level instrinsic. As a result, #2563 currently contains a workaround for #2598 which this PR would make unnecessary.This PR fixes the problem by factoring out the
func.prototype-tolerant property deletion into a separatecauterizePropertyfunction which it calls from both places. This PR also adds the test that was missing from #1221 , having first checked that the test detects #2598 when run without the rest of this PR.If this PR gets merged before #2563, then #2563's workaround for #2598 can first be removed before it is merged.
cauterizeProperty. @kriskowal , please advise how intrinsics.js should arrange to do so.Security Considerations
Allowing a
func.prototypeproperty that really shouldn't be there seems safe, so long as it is safely set toundefinedfirst, which this PR does, and then checks that it has done so.Scaling Considerations
none
Documentation Considerations
generally, this would be one less thing to worry about, and thus one less thing that needs to be documented for most users.
Testing Considerations
Adds the test that was missing from #1221 that let #2598 go unnoticed until #2563
Compatibility Considerations
Should be none.
Upgrade Considerations
Should be none.