Skip to content
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

Disallow destructuring internalbinding c #54023

Closed

Conversation

Ceres6
Copy link
Contributor

@Ceres6 Ceres6 commented Jul 24, 2024

follow up of #53947

@nodejs-github-bot
Copy link
Collaborator

Review requested:

  • @nodejs/crypto
  • @nodejs/http
  • @nodejs/net

@nodejs-github-bot nodejs-github-bot added lib / src Issues and PRs related to general changes in the lib or src directory. needs-ci PRs that need a full CI run. labels Jul 24, 2024
@Ceres6
Copy link
Contributor Author

Ceres6 commented Jul 24, 2024

I have created the typings for crypto, I don't mind creating the rest, but I wanted to check that I had the correct approach

setFipsCrypto(bool: boolean): void;
getSSLCiphers(): unknown;
getRootCertificates(): unknown;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you make sure all files have an EOL?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done!

@joyeecheung
Copy link
Member

Isn't this something that only matter for certain internal bindings that use the binding object as a receiver, and doesn't apply to all binding objects? Disallowing destructing on all other unrelated bindings would lead to a perf cost and for bindings that are public, this allows users to modify them and affect internals.

@joyeecheung
Copy link
Member

I think a better way to enforce the fast API dependency on creation context may be - do not use the receiver. Just make that part of the API - always pass the binding object as the first argument. The linter configs that disallow destructing is not strong enough - someone can still do const method = binding.method, and then invoke it without the binding. But if we enforce that it must be called as method(binding, ...), then it'd be safer.

Copy link
Member

@mcollina mcollina left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@@ -27,22 +27,10 @@ const {

const tls = require('tls');

const {
codes: {
ERR_TLS_INVALID_PROTOCOL_VERSION,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Destructing symbols and constants should be safe and disallowing this could be way too verbose.

@Ceres6
Copy link
Contributor Author

Ceres6 commented Jul 26, 2024

@joyeecheung I'm happy to implement your approach, but I'd need some guidance on how to do it and how to identify which bindings need to enforce it

@Ceres6
Copy link
Contributor Author

Ceres6 commented Aug 7, 2024

@anonrig can you help me unblock this?

@joyeecheung
Copy link
Member

joyeecheung commented Aug 15, 2024

I'm happy to implement your approach, but I'd need some guidance on how to do it and how to identify which bindings need to enforce it

Basically, look for all the fast APIs (you can probably easily find them by searching CFunction::Make) and check the arguments of the fast API callbacks - if the first argument is a receiver that actually gets used in the callback, insert a second Local<Object> argument and use it instead, ignoring the first argument in C++, then update all corresponding JS land calls to pass the original receiver as the first JS call argument (which corresponds to the second argument of the C++ fast API callback).

@Ceres6
Copy link
Contributor Author

Ceres6 commented Aug 16, 2024

@joyeecheung I created a draft PR with the changes for fs.internalModuleStat adding the receiver as second argument. It would be very helpful if you could take a look to see if I'm on the right track before migrating all the rest, as there are bunch of occurrences.

@Ceres6 Ceres6 closed this Sep 28, 2024
@Ceres6
Copy link
Contributor Author

Ceres6 commented Sep 28, 2024

Closing in favour of #54408

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lib / src Issues and PRs related to general changes in the lib or src directory. needs-ci PRs that need a full CI run.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants