-
Notifications
You must be signed in to change notification settings - Fork 29.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
child_process: ensure message sanity at send source #24787
Conversation
lib/internal/child_process.js
Outdated
// end point; as any failure in the strinfication there | ||
// will result in error message that is weekly consumable. | ||
// So perform a sanity check on message prior to sending. | ||
const ret = JSON.stringify(message); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Calling JSON.stringify()
twice is wasteful. Cache the result and use it on line 730.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unfortunately, the message
undergoes change in all the possible control flows between here and line 730, so cached value is unusable.
Another alternative is to delay this sanity check to as late as line 730 where there is already a stringification, don't know whether it can have side effects or not - thoughts please?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will only guard against three input types: undefined
, function
and symbol
. All other values either throw (e.g., any input that includes a BigInt) or the non-serializable part would be omitted or replaced with the string 'null'
(with the exception of the object containing an toJSON
function which returns undefined).
There are lots of inputs which would also be problematic which would not be caught here. I actually doubt that we really have to guard against anything else than undefined
. So let's just use a simple type check instead of using JSON.stringify
:
if (typeof message !== 'string' &&
typeof message !== 'object' &&
typeof message !== 'number' &&
typeof message !== 'boolean') {
throw new ERR_INVALID_ARG_TYPE(
'message', ['string', 'object', 'number', 'boolean'], message);
}
The reason why I would do the check like this is that in the default case the message is either a string or an object. Other type checks would not be necessary anymore. While doing it the other way around would require to always check for undefined
, bigint
, symbol
and function
. The error message is also a bit clearer that way.
This will not guard against a weird toJSON
function but that should be fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@BridgeAR - I followed your suggestions, PTAL.
more than a month with no reviews and approvals; can I have one please! |
lib/internal/child_process.js
Outdated
// end point; as any failure in the strinfication there | ||
// will result in error message that is weekly consumable. | ||
// So perform a sanity check on message prior to sending. | ||
const ret = JSON.stringify(message); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will only guard against three input types: undefined
, function
and symbol
. All other values either throw (e.g., any input that includes a BigInt) or the non-serializable part would be omitted or replaced with the string 'null'
(with the exception of the object containing an toJSON
function which returns undefined).
There are lots of inputs which would also be problematic which would not be caught here. I actually doubt that we really have to guard against anything else than undefined
. So let's just use a simple type check instead of using JSON.stringify
:
if (typeof message !== 'string' &&
typeof message !== 'object' &&
typeof message !== 'number' &&
typeof message !== 'boolean') {
throw new ERR_INVALID_ARG_TYPE(
'message', ['string', 'object', 'number', 'boolean'], message);
}
The reason why I would do the check like this is that in the default case the message is either a string or an object. Other type checks would not be necessary anymore. While doing it the other way around would require to always check for undefined
, bigint
, symbol
and function
. The error message is also a bit clearer that way.
This will not guard against a weird toJSON
function but that should be fine.
lib/internal/child_process.js
Outdated
// will result in error message that is weakly consumable. | ||
// So perform a sanity check on message prior to sending. | ||
const ret = JSON.stringify(message); | ||
if (ret == null) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ret
can never be null
. If null
is passed through as message JSON.stringify()
would return the string 'null'
.
JSON.stringify() either returns undefined
or a string
or it throws.
ping @BridgeAR |
can I get a review here pls? |
65ac601
to
8b981fa
Compare
Error messages coming out of de-serialization at the send target is not consumable. So detect the scenario and fix it at the send source Ref: nodejs#20314 PR-URL: nodejs#24787 Reviewed-By: Luigi Pinca <[email protected]>
8b981fa
to
daa97df
Compare
landed as daa97df |
Error messages coming out of de-serialization at the send target is not consumable. So detect the scenario and fix it at the send source Ref: nodejs#20314 PR-URL: nodejs#24787 Reviewed-By: Luigi Pinca <[email protected]>
Error messages coming out of de-serialization at the send target is not consumable. So detect the scenario and fix it at the send source Ref: #20314 PR-URL: #24787 Reviewed-By: Luigi Pinca <[email protected]>
Error messages coming out of de-serialization at the send target is not consumable. So detect the scenario and fix it at the send source Ref: #20314 PR-URL: #24787 Reviewed-By: Luigi Pinca <[email protected]>
Error messages coming out of de-serialization at the send target is not consumable. So detect the scenario and fix it at the send source.
Ref: #20314
existing error message (sample code in the linked issue):
with this change:
/cc @vsemozhetbyt @joyeecheung @nodejs/child_process
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes