Repository navigation
Can we have "unsecure" features in Node.js? #1274
Description
Should there be a note about security in the docs? Specifically, I am wondering what would constitute a vulnerability here.
Originally posted by @tniessen in nodejs/node#45096 (comment)
In the PR linked above, I'm suggesting adding a static HTTP server that is targeted for development only, i.e. not meant to be production ready (ever, likely). Is there a way to make sure that bugs that will be found in this implementation will not result in security releases?
I think there is value to have this feature built-in (it's already available via npm packages, but having to add a dev dependency for such a simple feature seems silly), but it's unclear if it's worth it if it results in a flow of security vulnerability reports.
Activity
mhdawson commentedon Apr 10, 2024
I'll be interested in listing to the discussion in the meeting since I can't make it. My first thought is that it will be a challenge to community/explain/justify why we exclude some parts of our APIs from vulnerability reports. We had discussion around doing so for experimental features and the consensus was that it was not the way to go at that point in time.
marco-ippolito commentedon Apr 11, 2024
I don't think it's a good idea to provide insecure features in core.
We will receive issue, and h1 reports even if we mark it as insecure, because users will rely on the feature and build products and libraries on top.
I think the expectation is that if something is stable, is secure for production.
A insecure feature would be something forever experimental.
I believe that would be more useful as a separate npm package.
UlisesGascon commentedon Apr 11, 2024
I agree with Marco. Seems like experimental is the way to go
RafaelGSS commentedon Apr 25, 2024
@aduh95 During today's security team meeting, we discussed the topic of adding an explicitly insecure feature to Node.js. Our consensus, for now, is that it is not a good choice. While having it built-in may seem convenient, it is not a strong enough argument to justify it being part of the core.
If you would like to discuss this further, we welcome you to join one of our meetings.
github-actions commentedon Jul 25, 2024
This issue has been inactive for 90 days. It will be closed in 14 days unless there is further activity or the stale label is taken off.