-
-
Notifications
You must be signed in to change notification settings - Fork 31.9k
lib: deprecate _tls_common and _tls_wrap #57643
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
lib: deprecate _tls_common and _tls_wrap #57643
Conversation
Review requested:
|
@BridgeAR I know you said that the runtime deprecation wasn't completely necessary but I really wanted to give it a shot (and I really like how it turned out 😄) I hope you don't mind 🙂 |
6d4746b
to
50c51bd
Compare
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #57643 +/- ##
==========================================
+ Coverage 90.12% 90.18% +0.06%
==========================================
Files 629 631 +2
Lines 186638 186662 +24
Branches 36618 36656 +38
==========================================
+ Hits 168202 168344 +142
+ Misses 11222 11122 -100
+ Partials 7214 7196 -18
🚀 New features to boost your workflow:
|
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.
lgtm
9d8afa9
to
0643430
Compare
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.
lgtm
f09a338
to
15a47d9
Compare
Type: Runtime | ||
|
||
The `node:_tls_common` and `node:_tls_wrap` modules are deprecated as they should be considered | ||
an internal nodejs implementation rather than a public facing API, use `node:tls` instead. |
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.
Just noting... it's an unfortunate truth that while these are deprecated we likely will never be able to actually remove them. See require('sys')
....
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.
oh I see.. that's pretty disappointing 🥲 (although I understand the security implications...)
I like your suggestion of throwing an error though, it'd be pretty nice if we could do that at some point 🙂
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.
mh... or maybe the _ modules could be removed at some point since npm doesn't support such modules anyways? 🤔
#26292 (comment)
https://github.com/npm/validate-npm-package-name?tab=readme-ov-file#naming-rules
🤔
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.
npm may not but an attacker could still locally inject a module which would still be problematic.
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.
oh I see what you mean... like with a postinstall script or something that drops an _ module in the node_modules right? 🤔
oh too bad then 😓 (but I am still hoping for the throwing idea! 😀)
15a47d9
to
2ef23ad
Compare
runtime deprecate the _tls_common and _tls_wrap modules, users should use nust node:tls insteal and internally internal/tls/commond and internal/tls/wrap should be used instead
skip tests if crypo is missing
d03c289
to
49fd777
Compare
// NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, | ||
// DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR | ||
// OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE | ||
// USE OR OTHER DEALINGS IN THE SOFTWARE. |
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.
Best to leave the trademark headers in place even if the rest is being removed
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.
ok thanks 🙂
or should I move those to the new internal modules which contain the original copy-pasted code?
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.
Copyright comments restored (into the new files): f96445c
I hope this works for you 🙏
Landed in a822a1c |
This PR is for runtime deprecation of the
_tls_common
and_tls_wrap
modulesMy hope is to manage to gradually deprecate the various
_
modules that are not documentedand that should not be part of node.js' public API (for more context see: #57540 (comment))
Interestingly as you can see:

common and wrap expose respectively:
SecureContext
createSecureContext
translatePeerCertificate
and
TLSSocket
Server
createServer
connect
All of these, seem to already being re-exported by
node:tls
:node/lib/tls.js
Lines 389 to 394 in 186bbf7
the only exception being
translatePeerCertificate
(which I am not really very familiar with, but by the looks of itseems like a rather simple function that can be re-implemented externally)
So I don't think that deprecating these modules should have huge impacts to users and that importing from
node:tls
instead is a viable alternative@BridgeAR 🙂👍