Repository navigation
Let's make a plan for bad getters and toString() methods #12372
Description
Activity
Applied the "security" label as it may be concerned by this issue in, at least, some cases; please remove it if it's not relevant.
I think so far all collaborators have indicated in the discussions here that those issues can’t reasonably be considered security issues.
Reacted by Tobias NießenOne (rather extreme) option is to:
- quit using
-fno-exceptionsfor Node's C++ code - throw C++ exceptions when JS exceptions occur
- catch and ignore the exception at the V8 callback interface.
- quit using
I personally consider it a non-issue. I'd be more amenable if it was something you hit by accident but so far it's all been people playing at security researcher.
Reacted by Tobias NießenReacted by Oleksii Orlenko@tniessen By the way, your first comment (the one you deleted) about gradually updating everything to
MaybeLocal<Value>is on the ball. It's happening slowly but surely whenever we make updates.Thanks for the feedback. I'll close the issue. Feel free to continue the discussion.
Version: master
Platform: all
Subsystem: src
It seems like these types of issues get opened pretty frequently. Node accepts an object as input, and one of the properties on that object is a getter that throws an error. Similar problems exist with
toString()and others. It's usually reported as a security issue that bypasses JavaScript validation (when we have some in place) and crashes in the binding layer.I tried to fix one such issue and was told that instead of fixing ad hoc, we should come up with a plan. I agree with that idea. So, let's come up with a plan. Should we ignore the problem? Ensure that getters and other potential problematic methods are corrected in the JS layer? Something else?