refactor: ensure IpcRenderer is not bridgable

[MarshallOfSound]

It's a security footgun that IpcRenderer (unlike everything else) can go over the context bridge by accident. Let's just make it so it can't

Notes: no-notes

[miniak]

@MarshallOfSound would it make sense to do this as well for consistency?

class IpcRendererInternal extends EventEmitter implements ElectronInternal.IpcRendererInternal {
  send (channel: string, ...args: any[]) {
    return ipc.send(internal, channel, args);
  }

  sendSync (channel: string, ...args: any[]) {
    return ipc.sendSync(internal, channel, args);
  }

  async invoke<T> (channel: string, ...args: any[]) {
    const { error, result } = await ipc.invoke<T>(internal, channel, args);
    if (error) {
      throw new Error(`Error invoking remote method '${channel}': ${error}`);
    }
    return result;
  };
}

export const ipcRendererInternal = new IpcRendererInternal();

[MarshallOfSound]

@miniak Oh yeah sure

[dsanders11]

Should this be considered a breaking change? In #40321 the docs are being updated to avoid the footgun pattern, but currently the IPC tutorial said "In the renderer process, use the event parameter to send a reply back to the main process [...]" (and gave a code example doing so). If someone followed that tutorial, won't this change break their code?

[MarshallOfSound]

Should this be considered a breaking change?

In the sense we could note it somewhere, probably, in the sense that it's semver/major no. Security fixes aren't considered semver/major. No plans to backport this one though

[dsanders11]

In the sense we could note it somewhere, probably

Let's add it to breaking changes then. 👍

[jkleinsc]

Looks like this change is causing the node feature does not hang when using the fs module in the renderer process test to fail.

[release-clerk]

No Release Notes