Details

Isn't tlssocket kind of TCP? How to send RST on a tls connection?

Node.js version

18

Example code

const tlssocket = require('tls').connect({
    port: 443,
    host: 'www.example.com',
})
.on('secureConnect', () => {
    tlssocket.resetAndDestroy();
});

TypeError [ERR_INVALID_HANDLE_TYPE]: This handle type cannot be sent
    at new NodeError (node:internal/errors:393:5)
    at Socket.resetAndDestroy (node:net:700:13)
    at TLSSocket.<anonymous> (/path/to/test.js)
    at TLSSocket.emit (node:events:513:28)
    at TLSSocket.onConnectSecure (node:_tls_wrap:1576:10)
    at TLSSocket.emit (node:events:513:28)
    at TLSSocket._finishInit (node:_tls_wrap:952:8)
    at ssl.onhandshakedone (node:_tls_wrap:733:12)

Operating system

Not applicable.

Scope

runtime

Module and version

net tls

the first one intend to express that, the value new Proxy(()=>{},{}) is a no-side-effects function.

a gui sandbox software, drag a folder in and run it. i can't control what's included in users' folder path. currently, i can only shut down the software when path including special chars.

And * conflict can also use --permission-fs-path-matcher= to resolve. Then I may use --permission-fs-path-delimiter=//,// --permission-fs-path-matcher=//*// to end this issue. This way can also add other special functional char in the furture via --permission-fs-path-xxx=.

I prefer to use --permission-fs-path-delimiter=// (any other char will still meet possible conflict) in my use case to resolve delimiter problem forever without break change.

Suggestion

🔍 Search Terms

✅ Viability Checklist

My suggestion meets these guidelines:

• [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
• [x] This wouldn't change the runtime behavior of existing JavaScript code
• [x] This could be implemented without emitting different JS based on the types of the expressions
• [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• [x] This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

Currently, ts treat import url as path, not url (remove search / hash and decodeURIComponent firstly).

Is it possible to support decodeURIComponent for import url, at least for "moduleResolution": "NodeNext" / "bundler", or url in format with scheme like http://example.com/%3F.js?version or file:./path%25, because that's the standard behaviour of Node.js / browser?

📃 Motivating Example

import './path%25.mjs';// actually expect './path%.mjs', not './path%25.mjs'

💻 Use Cases

import filename including \ % ? #.

Feature Use Case

const noop = /*#__NO_SIDE_EFFECTS__*/new Proxy(()=>{},{});

noop();

Feature Proposal

sample above will be ignored.

there seems no reason not to make it same as:

const noop = /*#__NO_SIDE_EFFECTS__*/()=>{};

noop();

Suggestion

🔍 Search Terms

✅ Viability Checklist

My suggestion meets these guidelines:

• [ ] This wouldn't be a breaking change in existing TypeScript/JavaScript code
• [ ] This wouldn't change the runtime behavior of existing JavaScript code
• [ ] This could be implemented without emitting different JS based on the types of the expressions
• [ ] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• [ ] This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

Currently, ts treat url of import as path (/path#.ts), not url (file:///path%23.ts).

Is it possible to support decodeURIComponent in import url, at least for "moduleResolution": "Node" / "NodeNext" / "bundler", because that's the standard behaviour of Node.js / browser?

📃 Motivating Example

import './a%23b';// not equal to './a#b'

💻 Use Cases

import path including \ % ? #.

<!-- Thank you for submitting a pull request!

Please verify that:

• [ ] There is an associated issue in the Backlog milestone (required)
• [x] Code is up-to-date with the main branch
• [ ] You've successfully run gulp runtests locally
• [ ] There are new or updated unit tests validating the change

Refer to CONTRIBUTING.MD for more details. https://github.com/Microsoft/TypeScript/blob/main/CONTRIBUTING.md

** Please don't send typo fixes! ** Please don't send a PR solely for the purpose of fixing a typo, unless that typo truly hurts understanding of the text. Each PR represents work for the maintainers, and that work should provide commensurate value.

If you're interested in sending a PR, the issue tracker has many issues marked help wanted. -->

Fixes #50168

Do you want to keep working on this? Otherwise I'd like to close it to reduce the number of open PRs.

Sorry, I can't...

ERROR in ./node_modules/@ltd/j-toml/index.js 356:28
Module parse failed: Unexpected token (356:28)
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders
| 
| class mark {
>                        lineIndex = lineIndex;
|                        type                                                                                           ;
|                        restColumn        ;

Your parser doesn't support class field syntax. Update webpack version to resolve this.

Details

1. [ ] from any os memory on the machine
2. [ ] only from the process itself gc

If 1, I think need to use --zero-fill-buffers for sandbox process; if 2, without unnecessary use of --zero-fill-buffers, there will be better performance.

So which is it? And I'm I right that if 1, --zero-fill-buffers is unnecessary for security? Or it will still leak some information I can't imagine?

Node.js version

Any, at least for the future.

Example code

No response

Operating system

any

Scope

runtime

Module and version

No response

Thank you!

Details

1. [ ] from any os memory on the machine
2. [ ] only from the process itself gc

If 1, I think need to use --zero-fill-buffers for sandbox process; if 2, without unnecessary use of --zero-fill-buffers, there will be better performance.

So which is it? And I'm I right that if 1, --zero-fill-buffers is unnecessary for security? Or it will still leak some information I can't imagine?

Node.js version

Any, at least for the future.

Example code

No response

Operating system

any

Scope

runtime

Module and version

No response

The doc said that's "process-based permission". But it's actually based on execArgv, does it mean that, it can also be used for create worker by design (and "process-based" is a only provisional loose wording used to emphasize the difference from "module-based")?

You can call main thread-based permission, yeah.

What about other threads?

What's your use case?

Thank you for your attentive.

I'm making a sandbox util to run test pure code and keep them away from disk.

There are many codes to run, so if I can use new worker_threads.Worker 100 times instead of child_process.fork 100 times, the cost will be less.

Currently, my code looks like sample 1 because the docs said it's "process-based permission":

function fn (id) {
    return child_process.fork(`/path/to/${id}.js`, [], {
        execArgv: [ '--experimental-permission', '--allow-fs-read=/path/to/${id}.js' ]
    });
}

And if actually it's "thread-based permission", I want to make it looking like sample 2:

function fn (id) {
    return worker_threads.Worker(`/path/to/${id}.js`, {
        execArgv: [ '--experimental-permission', '--allow-fs-read=/path/to/${id}.js' ]
    });
}

So actually --experimental-permission is not a "process-based permission", but "thread-based permission"?

The doc said that's "process-based permission". But it's actually based on execArgv, does it mean that, it can also be used for create worker by design (and "process-based" is a only provisional loose wording used to emphasize the difference from "module-based")?

--experimental-policy accept file:/// url, if we also support --allow-fs-read=file:///path%2C1/%2A,file:///path%2C2/* may resolve this problem.

@RafaelGSS

@lukastaegert here ready if I add the test right