Repository navigation
Warn on insecure environment options / CLI flags #21774
Description
Activity
- changed the title
[-]Warn on insecure Node.js environment options / CLI flags[/-][+]Warn on insecure environment options / CLI flags[/+]on Jul 12, 2018 I'm in favor of such a change.
I also think that we might not want to allow to change
NODE_DEBUGandNODE_TLS_REJECT_UNAUTHORIZEDat runtime, or that we should sample those values at startup.Reacted by Nikita Skovoroda and Marcin HoppeI've wanted these kinds of warnings since I introduced emitWarning. It was part of my original use case for it. Big +1
Reacted by Nikita Skovoroda and mary marchiniI’m on board with warnings for all three situations you’re suggesting.
I don’t think we need to prohibit programmatic usage, though. Printing a warning is already close enough to effectively break a feature in a lot of circumstances.
This would definitly make sense to me 👍
👍 from me, too. Developers and operations people alike might not be aware of but hopefully a warning will be picked up by any monitoring / alerting system in use.
Should we also include an option to suppress this warning for people who have a legitimate reason to run with this setting?
@MarcinHoppe There is already an
--no-warningsoption to suppress warnings from Node.js, that should suppress these too.I am not sure if there needs to be a one to suppress just these kind of warnings (or perhaps even a specific warning only). I don't want to overengineer it from the start, so perhaps it would make sense to add that in case if someone who would actually need it asks?
Reacted by antsmartianI don't want to overengineer it from the start, so perhaps it would make sense to add that in case if someone who would actually need it asks?
I wholeheartedly endorse this approach :). 👍 from me.
- added a commit that references this issue
on Jul 23, 2018 - added a commit that references this issue
on Nov 6, 2018 - added a commit that references this issue
on Nov 6, 2018 - added a commit that references this issue
on Nov 29, 2018 - added 2 commits that reference this issue
on Nov 29, 2018
Note: this is not about deprecation, it is about printing runtime warnings about security impact of some of the Node.js environment options. That would probably be a semver-major change.
Environment options are more dangereous because:
npm) with those than modify them to use unsafe API.I have seen npm credentials in logs from npm being run with
NODE_DEBUG=httpand those logs being attached to issues.I have seen modules setting
NODE_TLS_REJECT_UNAUTHORIZED.So far, the ones that I am aware of:
NODE_TLS_REJECT_UNAUTHORIZED=0(Propose NODE_TLS_REJECT_UNAUTHORIZED be renamed #5258),NODE_DEBUG=http(exposes auth data, logs are unsafe to share),--inspect=0.0.0.0flag? Not an env var, but highly copy-pasted.Anything else?
I also would like some discussion here, as I am not sure if that is the best approach in this situation.
/cc @nodejs/security-wg