💖 Thanks for opening this pull request! 💖

We use semantic commit messages to streamline the release process. Before your pull request can be merged, you should update your pull request title to start with a semantic prefix.

Examples of commit messages with semantic prefixes:

• fix: don't overwrite prevent_default if default wasn't prevented
• feat: add app.isPackaged() method
• docs: app.isDefaultProtocolClient is now available on Linux

Things that will help get your PR across the finish line:

• Follow the JavaScript, C++, and Python coding style.
• Run npm run lint locally to catch formatting errors earlier.
• Document any user-facing changes you've made following the documentation styleguide.
• Include tests when adding/changing behavior.
• Include screenshots and animated GIFs whenever possible.

We get a lot of pull requests on this repo, so please be patient and we will get back to you as soon as we can.

The build failures seem to be failing with src cache was not restored for some reason, idk what happened here... when checking to see if src/third_party/blink is in the checkout. I'm not sure exactly what I can do with that, since it does not appear I have the ability to rerun the failure to see if it was transient (or if that's simply not a normal thing to do in cases like these). Please let me know if there's something I can do or missed in the PR.

Thanks for the reply and explanation, I appreciate the time you are taking to provide guidance.

@baparham as a rule, we don't update Node.js versions in existing stable releases.

Are the beta releases considered a stable channel? I wouldn't expect us to jump to node 20 for example, or perhaps even a new minor version of node after being promoted to Beta, but a patch version update to node with the benefit of non-trivial security fixes seems like a reasonable risk/reward ratio as a user.

Are there specific security fixes you're interested in?

The c-ares fixes are mostly what I'm interested in.

I believe the openssl fixes with the update to 3.0.9 are irrelevant, since we use boringssl, so the CVEs worth including are in c-ares and node.js directly:

This version of node.js updated c-ares to 1.19.1 which included these CVE fixes:
GHSA-9g78-jv2r-p7vc
GHSA-8r8p-23f3-64c2
GHSA-54xr-f67r-4pc4
GHSA-x6mf-cxr9-8q6v

There are also 3 high and 7 medium node.js specific security fixes that were outlined in the release blog I posted in the description too. I do not know if any have been patched in to Electron, but I assume none or very few would have been patched in as standalone fixes based on the changes in 327af3b not hinting that any patches were no longer required by Electron

hey @baparham - as an update, this isn't off the table. We're discussing policy for this right now and seeing if we can adjust to allow for patch updates during the beta phase.

✅ Approved on behalf of Releases WG.

As @codebytere mentioned above, the Releases WG has decided that as a policy, we'll approve patch bumps for Node by default if the alpha/beta is more than 2 weeks out from stable release, and will vote on minor bumps on a case-by-case basis. This PR is approved for beta - it now just needs a code review, and we can merge. Thanks for submitting this PR!

Who should review this? @codebytere requested changes, but presumably they were related to the policy, which has been resolved.

What's left that I can help with? (also, thank you to whoever reran the failure in CI 🙏)

Congrats on merging your first pull request! 🎉🎉🎉

Release Notes Persisted

Updated Node.js to v18.16.1 to address security fixes.

For future reference, I am linking the policy changes here: electron/governance#546, #39163