/cc @bpasero

Note that this PR includes an update to the patches/node/src_preload_function_for_environment.patch, which I will separate into another PR once nodejs/node#51539 gets approved/merged.

The failing WoA test is from newly added one

not ok 156 default behavior app.setNodePreload throws when path outside of resources path is passed
  expected [Function] to throw error matching /The preload script must reside in resourcesPath/ but got 'The file path of preload script must be absolute.'
  AssertionError: expected [Function] to throw error matching /The preload script must reside in resourcesPath/ but got 'The file path of preload script must be absolute.'
      at Context.<anonymous> (electron\spec\api-app-spec.ts:2068:18)

API LGTM

It's not clear to me how this approach protects against e.g. prototype pollution. What is this trying to prevent?

In VS Code this will be used for 2 things:

1. Reset the module search paths to certain places for extensions.
2. Monkey-patch fs module to disallow access to UNC paths (UNC host '...' access is not allowed microsoft/vscode#182070).

Without this feature they have to patch Electron to implement the behaviors, because there is no way to inject scripts to workers or child processes.

I don't think they mean to prevent malicious extensions code, this is more about setting up an environment for extensions. @deepak1556 should know more about the security part.

Yes both the mentioned features are not protection against untrusted code executed in the process but rather against external actors, both the described features in VS Code are specific to Windows

1. We want to control module search paths in child process forked from our application, to remove world writable locations like C:/ from the search paths so that extensions don't unintentionally load a malicious module that can end up causing RCE for users sharing the same system. This does not fall under the threat model of Electron or Node.js, so the fix is specific to our application.

2. NTLM hash leaks is a known issue on Windows and the problem lies at the system read/write calls. There is not much a runtime can do here but the best course is to prompt the user before making any sort of I/O with a UNC path. Since there are numerous places this can happen from our application, we wanted to gate the checks at the Node.js fs layer to ensure any I/O from the application will be checked against an allowed set of UNC hosts explicitly consented by the user before proceeding. We are hoping this change can be removed once NTLM auth is removed on Windows, refs https://techcommunity.microsoft.com/t5/windows-it-pro-blog/the-evolution-of-windows-authentication/ba-p/3926848

Both the changes are additional checks on top of what Electron/Node.js provides, so the preload API seems a better alternative to maintain the changes at the application layer rather than maintaining them as patch in the custom fork of the runtime.