fix(ses): update permits for stage 2.7.4 proposals #2693
+73
−11
Conversation
This file contains 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
kriskowal
approved these changes
Jan 22, 2025
|
|
||
| // /~https://github.com/tc39/proposal-source-phase-imports | ||
| // TODO %AbstractModuleSource%, ModuleSource? | ||
| // ModuleSource: 'ModuleSource', |
There was a problem hiding this comment.
ModuleSource already appears below.
kriskowal
changed the title
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: #XXXX
Refs: /~https://github.com/tc39/proposals
Description
The
permits.jsfile should stay reasonably up to date with /~https://github.com/tc39/proposals stage 4, 3, and 2.7 proposals. Those it is not yet ready to list, it should at least include in a TODO comment. For non-ancient proposals, each such entry should cite the proposal url.Security Considerations
The entire reason for the permits mechanism is so that elements added to the primordials are not enabled for Hardened JS until the Hardened JS stewards have vetted them. This is mostly by having vetted the specs during the proposal process, assuming that the implementations follow the spec correctly enough for security purposes. When we later find that an implementation has not, this is a separate security concern to be dealt with then, probably by repair, but conceivably by withdrawing the permit.
Reviewers: Therefore, when reviewing each newly permitted entry, please think about whether it may threaten any security property of Hardened JS.
Scaling Considerations
none
Documentation Considerations
The closer we stay to permitting the JS that is shipping, and that developers have come to expect, the fewer surprises we need to explain.
Testing Considerations
Not sure what would help. Suggestions welcome.
Compatibility Considerations
Code that was feature testing for one of these new features might find one present that had previously been absent. If both branches of the code are correct, well, that is why it feature tests, so all is happy. However, the newly taken branch may have been previously untested.
Upgrade Considerations
See the discussion above about feature testing. Such code, even when correct on both branches, may fail to deterministically replay a previous run done without the feature.