Repository navigation
Conversation
…coder that shipped in some versions of chrome prior to 127
|
kriscendobot
added a commit
to endojs/endo-but-for-bots
that referenced
this pull request
Oct 7, 2026
…nstructors lockdown() now replaces the host TextEncoder and TextDecoder constructors, before the intrinsics collector samples the global object, with SES-owned constructors that delegate construction to the captured host originals and share the host prototypes. The permitted codec intrinsics are therefore SES-owned on every engine, and the host constructor objects -- restricted properties and all -- never enter the permitted intrinsics graph, so lockdown() completes on the affected engines (V8 up to and including Chrome 137). The restricted-property descriptor shape is indistinguishable from the live caller and arguments slots of a sloppy function, so neither tolerating it in cauterizeProperty nor permitting it (endojs/endo#3371) would be safe; encapsulation sidesteps the exposure decision entirely. Instances are constructed by the host constructors and the prototypes are the host prototypes, so instanceof, subclassing, encode, encodeInto, streaming decode, decoder labels and options, and the encoding, fatal, and ignoreBOM getters all retain host behavior. Fixes endojs/endo#3369 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
kriscendobot
added a commit
to endojs/endo-but-for-bots
that referenced
this pull request
Oct 7, 2026
…nstructors lockdown() now replaces the host TextEncoder and TextDecoder constructors, before the intrinsics collector samples the global object, with SES-owned constructors that delegate construction to the captured host originals and share the host prototypes. The permitted codec intrinsics are therefore SES-owned on every engine, and the host constructor objects -- restricted properties and all -- never enter the permitted intrinsics graph, so lockdown() completes on the affected engines (V8 up to and including Chrome 137). The restricted-property descriptor shape is indistinguishable from the live caller and arguments slots of a sloppy function, so neither tolerating it in cauterizeProperty nor permitting it (endojs/endo#3371) would be safe; encapsulation sidesteps the exposure decision entirely. Instances are constructed by the host constructors and the prototypes are the host prototypes, so instanceof, subclassing, encode, encodeInto, streaming decode, decoder labels and options, and the encoding, fatal, and ignoreBOM getters all retain host behavior. SES-for-XS builds its shim compartment constructor from a global intrinsics sample taken at module load, before lockdown() runs, so the taming is idempotent and SES-for-XS also tames at module load; compartments and the start compartment then agree on the SES-owned codec identities under xst, which provides both codecs. Fixes endojs/endo#3369 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
kriscendobot
added a commit
to endojs/endo-but-for-bots
that referenced
this pull request
Oct 27, 2026
…nstructors lockdown() now replaces the host TextEncoder and TextDecoder constructors, before the intrinsics collector samples the global object, with SES-owned constructors that delegate construction to the captured host originals and share the host prototypes. The permitted codec intrinsics are therefore SES-owned on every engine, and the host constructor objects -- restricted properties and all -- never enter the permitted intrinsics graph, so lockdown() completes on the affected engines (V8 up to and including Chrome 137). The restricted-property descriptor shape is indistinguishable from the live caller and arguments slots of a sloppy function, so neither tolerating it in cauterizeProperty nor permitting it (endojs/endo#3371) would be safe; encapsulation sidesteps the exposure decision entirely. Instances are constructed by the host constructors and the prototypes are the host prototypes, so instanceof, subclassing, encode, encodeInto, streaming decode, decoder labels and options, and the encoding, fatal, and ignoreBOM getters all retain host behavior. SES-for-XS builds its shim compartment constructor from a global intrinsics sample taken at module load, before lockdown() runs, so the taming is idempotent and SES-for-XS also tames at module load; compartments and the start compartment then agree on the SES-owned codec identities under xst, which provides both codecs. Fixes endojs/endo#3369 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
kriscendobot
added a commit
to endojs/endo-but-for-bots
that referenced
this pull request
Oct 28, 2026
…nstructors lockdown() now replaces the host TextEncoder and TextDecoder constructors, before the intrinsics collector samples the global object, with SES-owned constructors that delegate construction to the captured host originals and share the host prototypes. The permitted codec intrinsics are therefore SES-owned on every engine, and the host constructor objects -- restricted properties and all -- never enter the permitted intrinsics graph, so lockdown() completes on the affected engines (V8 up to and including Chrome 137). The restricted-property descriptor shape is indistinguishable from the live caller and arguments slots of a sloppy function, so neither tolerating it in cauterizeProperty nor permitting it (endojs/endo#3371) would be safe; encapsulation sidesteps the exposure decision entirely. Instances are constructed by the host constructors and the prototypes are the host prototypes, so instanceof, subclassing, encode, encodeInto, streaming decode, decoder labels and options, and the encoding, fatal, and ignoreBOM getters all retain host behavior. SES-for-XS builds its shim compartment constructor from a global intrinsics sample taken at module load, before lockdown() runs, so the taming is idempotent and SES-for-XS also tames at module load; compartments and the start compartment then agree on the SES-owned codec identities under xst, which provides both codecs. Fixes endojs/endo#3369 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Member
|
Superseded by #3376 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes: #3369
Description
Proposed Permits tweak to prevent
lockdownfrom failing in some unfortunate versions of Chromesee #3369
Security Considerations
Only allows a descriptor that contains a null, so any other value is still not permitted.
One drawback of doing it with a permit instead of a fallback in
cauterizePropertyis a configurable field will remain allowed.Scaling Considerations
Documentation Considerations
Could document where the inconsistency in Chrome is coming from.