feat(ses): update lockdown init and enable Hermes VM#2723
Conversation
69a97f5 to
7e2b07a
Compare
fa54256 to
5793270
Compare
1e87397 to
063ec33
Compare
8cf7a5e to
d0269ff
Compare
|
|
||
| if (evalTaming === 'unsafe-no-direct') { | ||
| evaluator = () => { | ||
| throw TypeError( |
There was a problem hiding this comment.
Does this take care of all three evaluators: eval, Function, Compartment (or just Compartment evaluate)?
'no-eval' should have the same effect on Compartments as 'unsafe-no-direct'. Why is it a separate code path? Are there any differences observable from within a Compartment?
There was a problem hiding this comment.
This is only covering Compartment evaluate.
We've introduced unsafe-no-direct with the intention of creating a variant of unsafe-eval where root compartment evaluators remain untouched but due to inability to use direct eval we have to throw from Compartment evaluate.
The intention is to allow the program to use Function or eval for some of the basic tasks they're sometimes used for in the ecosystem (like checking code for syntax errors), and we have some ideas for what we could do to implement evaluators in absence of direct eval. It does not undermine the value of having a locked-down environment while not bundling with inline compartments yet.
| // We reach here if the Function() constructor is outright forbidden by a | ||
| // strict Content Security Policy (containing either a `default-src` or a | ||
| // `script-src` directive), not been implemented in the host, or the host | ||
| // is configured to throw an exception instead of `new Function`. |
There was a problem hiding this comment.
Shouldn't 'no-eval' also disallow these?
There was a problem hiding this comment.
This is where we check what the capabilities of the host are.
no-eval should have an effect after this check.
If the above is not correct, we have to look into running this earlier or changing the logic of asserting on the results of probeHostEvaluators a bit.
|
noting iterations for posterity
|
|
@Jack-Works , this PR is now proceeding under the assumption that it would be ok with you to change the behavior of Would that change in |
Yes, it's ok with me. I'm only using this on platforms with direct eval available |
This comment was marked as resolved.
This comment was marked as resolved.
|
@erights i've rebased the 9 commits into 6 and ready for merge, unless any further feedback |
| @@ -1,4 +1,12 @@ | |||
| User-visible changes in `ses`: | |||
| <!-- markdownlint-disable MD041 --> | |||
There was a problem hiding this comment.
What does this line mean? Does the need for this have something to do with this PR, or is it a drive-by? Did you use some kind of yarn format-like or prettier-like thing for .md files? Should we bundle that in to yarn format (though not in this PR)? If so, please at least file an issue.
In any case, no change suggested.
There was a problem hiding this comment.
sorry i resolved #2723 (review) too early, exactly we should add a script (or include it in yarn format) then ensure it's run in CI (example)
There was a problem hiding this comment.
you're right it's out of scope of this PR, filed issue here
There was a problem hiding this comment.
reverted formatting changes in the end to keep this PR relevant/minimal and not step on any toes
all .md docs in the codebase better updated when addressing the filed issue then reviewed separetely
| or setting the environment variable | ||
|
|
||
| ```sh | ||
| $ export LOCKDOWN_ERROR_TAMING=unsafe |
There was a problem hiding this comment.
Was the $ removal manual or by the .md fixer thing?
I do mildly prefer keeping the $ prefix so readers can easily see this is shell and not js.
There was a problem hiding this comment.
yep .md fixer https://github.com/DavidAnson/markdownlint/blob/v0.37.4/doc/md014.md
Rationale: It is easier to copy/paste and less noisy if the dollar signs are omitted when they are not needed. See https://cirosantilli.com/markdown-style-guide#dollar-signs-in-shell-code for more information.
There was a problem hiding this comment.
Because some commands do not produce output, it is not a violation if some commands do not have output:
$ mkdir test
mkdir: created directory 'test'
$ ls test
seems a bit silly that some doesn't include one command with no output 😄
There was a problem hiding this comment.
I do mildly prefer keeping the
$prefix so readers can easily see this is shell and not js.
agree ^ added exception <!-- markdownlint-disable MD014 -->
|
officially closes non-blocking compat improvements now tracked in updated |
|
nb: next release (ses@1.13.0) to plug into Metro for bundling React Native apps |
happy to expand current NEWS.md update in follow-up a PR to be more newsworthy (; which i imagine would land on https://github.com/endojs/hardenedjs.org/tree/main/src/content/docs/blog i foresee the blog post could detail
|
Closes: #1891 (tracker), tested on #2334, Endo Sync: 2025-01-29
Previous iterations: #2723 (comment)
TODO
legacyHermesTaming: safe (default), unsafe4th option undefined, warn (with new error reporter) to use the new lockdown optionsince getEnvironmentOption default must be a string ('all'), warn instead of SES_DIRECT_EVAL error with a strict CSPdisable compartment-shim when bundling ses for hermesdisable: globalThis Compartment and testCompartmentHooksvs camelCase--disallow-code-generation-from-stringsuseful node flag to emulate a strict csp runtime in testsFollow-up: new Compartment() fails on removeUnpermittedIntrinsics at
Tolerating undeletable intrinsics.%CompartmentPrototype%.importNow.prototype === undefinedUncaught TypeError: property is not configurabletest branch https://github.com/endojs/endo/tree/ses-hermes-p2 (from #2334)
yarn build:hermesbundle ses for hermesyarn test:hermesrun ses/test/_hermes-smoke.jsHermes eval behaviour on
bin/hermesc(standalone compiler) andbin/hermes(vm, eshost)