Conversation
|
I would expect a test to cover this here if we do that change. Also was this a problem you encountered or was the found by an agent ? |
|
@JeanMeche found by me through running our Node servers against security flags. |
…e patches
Loading zone.js under Node's --frozen-intrinsics (or SES lockdown,
or any environment that has frozen the relevant built-ins) crashes
at import. Two load_patches are responsible.
The toString patch dies trying to overwrite
Function.prototype.toString:
TypeError: Cannot assign to read only property 'toString' of
object 'function () { [native code] }'
The console patch dies one step earlier, when it tries to stash
the original method under a symbol-named property:
TypeError: Cannot add property __zone_symbol__dir, object is
not extensible
Node started freezing the console object a while back (see
nodejs/node#46044), so this is expected behavior on the runtime
side, not a Node bug — zone.js just isn't checking before it
writes.
The fix in both places is to look before leaping. For toString,
we inspect the descriptors of Function.prototype.toString and
Object.prototype.toString and skip the patch if either one isn't
writable or configurable. It has to be all-or-nothing: applying
only one of the two would make Promise objects stringify
differently depending on which path runs, which is worse than
not patching at all.
For console, we first check Object.isExtensible(console), then
check each method's descriptor individually. Console methods are
independent of each other, so a single locked-down method just
gets skipped while the rest are patched normally.
When the patches bail, you lose some behavior:
- Patched functions show their wrapper source through
Function.prototype.toString instead of looking like native
code. Anything that grep's for "[native code]" to detect
natives will see different output.
- console calls from inside a non-root zone stay in the calling
zone instead of being hoisted to Zone.root. The output still
appears; it's just in a different zone context. Most code
won't notice, but zone-aware logging setups might.
Neither is great, but both beat crashing at require().
Worth being clear about scope: this isn't "zone.js now works
under --frozen-intrinsics." The whole library is built around
mutating intrinsics, which is exactly what the flag forbids, so
that's a contradiction we can't resolve. The goal here is just
that the library shouldn't crash on import. A couple of other
load_patches have similar issues (patchMethod especially) and
can be hardened the same way in follow-ups.
d157ea7 to
4f99b76
Compare
|
Silently dropping the patch seem a bit dangerous to me, also |
|
Hi @arturovt, thank you for the PR. However, we have decided not to accept this change. Since Thank you again for your effort! |
|
This pull request has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Loading zone.js under Node's --frozen-intrinsics (or SES lockdown, or any environment that has frozen the relevant built-ins) crashes at import. Two load_patches are responsible.
The toString patch dies trying to overwrite
Function.prototype.toString:
The console patch dies one step earlier, when it tries to stash the original method under a symbol-named property:
Node started freezing the console object a while back (see nodejs/node#46044), so this is expected behavior on the runtime side, not a Node bug — zone.js just isn't checking before it writes.
The fix in both places is to look before leaping. For toString, we inspect the descriptors of Function.prototype.toString and Object.prototype.toString and skip the patch if either one isn't writable or configurable. It has to be all-or-nothing: applying only one of the two would make Promise objects stringify differently depending on which path runs, which is worse than not patching at all.
For console, we first check Object.isExtensible(console), then check each method's descriptor individually. Console methods are independent of each other, so a single locked-down method just gets skipped while the rest are patched normally.
When the patches bail, you lose some behavior:
Patched functions show their wrapper source through Function.prototype.toString instead of looking like native code. Anything that grep's for "[native code]" to detect natives will see different output.
console calls from inside a non-root zone stay in the calling zone instead of being hoisted to Zone.root. The output still appears; it's just in a different zone context. Most code won't notice, but zone-aware logging setups might.
Neither is great, but both beat crashing at require().
Worth being clear about scope: this isn't "zone.js now works under --frozen-intrinsics." The whole library is built around mutating intrinsics, which is exactly what the flag forbids, so that's a contradiction we can't resolve. The goal here is just that the library shouldn't crash on import. A couple of other load_patches have similar issues (patchMethod especially) and can be hardened the same way in follow-ups.