Historical changes to Electron APIs will now be detailed in the docs.

Hi 👋, I'm Peter, the 2024 Google Summer of Code (GSoC) contributor to Electron.

Over the course of the GSoC program, I implemented an API history feature for the Electron documentation and its functions, classes, etc. in a similar fashion to the Node.js documentation: by allowing the use of a simple but powerful YAML schema in the API documentation Markdown files and displaying it nicely on the Electron documentation website.

Electron 32.0.0 已发布！ 包括升级 Chromium 128.0.6613.36，和 V8 12.8 以及 Node. js 20.16.2。

Electron 团队很高兴发布了 Electron 32.0.0！ 你可以通过 npm install electron@latest 或者从我们的发布网站下载它。 继续阅读此版本的详细信息。

如果您有任何反馈，请在 Twitter 或 Mastodon 上与我们分享，或加入我们的 Discord 社区！ Bug 和功能请求可以在 Electron 的问题跟踪器中报告。

重要变化​

重点内容​

• 在我们的文档中添加新的 API 版本历史，一个由 @piotrpdev 创建的功能，作为Google Summer 代码的一部分。 You can learn more about it in this blog post. #42982
• 从 Web 文件 API 中移除非标准 File.path 扩展。 #42053
• 尝试打开受阻止路径中的文件或目录时，将 Web File System API 中的故障路径与上游对齐。 #42993
• 将以下现有的导航相关API添加到 webContents.navigationHistory : canGoBack, goBack, canGoForward, goForward, canGoToOffset, goToOffset, clear。 旧的导航API现已被废弃。 #41752

架构（Stack）更新​

• Chromium128.0.6613.36
  • 128 新功能
  • 127 新功能
• Node 20.16.0
  • Node 20.16.0 博客
• V8 12.8

Electron 32 将 Chromium 从 026.0.6478.36 升级到 128.0.6613.36, Node 从 20.14.0 升级到 20.16.1 以及 V8 从 12.6 升级到 12.8。

新特性​

• 添加了对通过app模块的'login'事件，响应来自实用程序进程发起的认证请求的支持。 #43317
• 在CPUUsage结构中添加了cumulativeCPUUsage属性，该属性返回自进程启动以来使用的 CPU 时间的总秒数。 #41819
• 将以下现有的导航相关API添加到 webContents.navigationHistory: canGoBack, goBack, canGoForward, goForward, canGoToOffset, goToOffset, clear。 #41752
• 扩展 WebContentsView 以接受预先存在的 webContents 对象。 #42086
• 在nativeTheme中添加了一个新属性prefersReducedTransparency，该属性指示用户是否选择通过系统辅助功能设置来降低操作系统级别的透明度。 #43137
• 尝试打开阻塞路径中的文件或目录时，将文件系统访问 API 中的故障路径与上游对齐。 #42993
• 在 Linux 上启用 Windows 控制叠加层API。 #42681
• 在网络请求中启用 zstd 压缩。 #43300

重大更改​

移除: File.path​

Electron 的早期版本在 Web File 对象中添加了非标准 path 属性作为在渲染器中执行所有操作更为常见时处理本机文件的便捷方法。 然而它偏离了标准，并且也带来了较小的安全风险，因此从 Electron 32 开始它已被移除，取而代之的是 webUtils.getPathForFile 方法。

// Before (renderer)
const file = document.querySelector('input[type=file]');
alert(`Uploaded file path was: ${file.path}`);

// After (renderer)
const file = document.querySelector('input[type=file]');
electron.showFilePath(file);

// After (preload)
const { contextBridge, webUtils } = require('electron');

contextBridge.exposeInMainWorld('electron', {
  showFilePath(file) {
    // It's best not to expose the full file path to the web content if
    // possible.
    const path = webUtils.getPathForFile(file);
    alert(`Uploaded file path was: ${path}`);
  },
});

废弃：WebContents 中的 clearHistory, canGoBack, goBack, canGoForward, goForward, goToIndex, canGoToOffset, goToOffset​

在 WebContents 实例上与导航相关的API现在已被废弃。 这些API已被移动到WebContents的 navigationHistory 属性，以便为管理导航历史提供一个更有条理和直观的接口。

// Deprecated
win.webContents.clearHistory();
win.webContents.canGoBack();
win.webContents.goBack();
win.webContents.canGoForward();
win.webContents.goForward();
win.webContents.goToIndex(index);
win.webContents.canGoToOffset();
win.webContents.goToOffset(index);

// Replace with
win.webContents.navigationHistory.clear();
win.webContents.navigationHistory.canGoBack();
win.webContents.navigationHistory.goBack();
win.webContents.navigationHistory.canGoForward();
win.webContents.navigationHistory.goForward();
win.webContents.navigationHistory.canGoToOffset();
win.webContents.navigationHistory.goToOffset(index);

终止对 29.x.y 的支持​

根据项目的支持政策，Electron 29.x.y 已经达到了支持的终点。 我们鼓励开发者将应用程序升级到更新的 Electron 版本。

接下来​

在短期内，您可以期待团队继续专注于跟上构成 Electron 的主要组件的开发，包括 Chromium、Node 和 V8。

您可以在此处找到 Electron 的公开时间表。

有关这些和未来变化的更多信息可在计划的突破性变化页面找到。

Electron 31.0.0 已发布！ 包括升级 Chromium 126.0.6478.36，和 V8 12.6 以及 Node. js 20.14.2。

Electron 团队很高兴发布了 Electron 31.0.0 ！ 你可以通过 npm install electron@latest 或者从我们的发布网站下载它。 继续阅读此版本的详细信息。

如果您有任何反馈，请在 Twitter 或 Mastodon 上与我们分享，或加入我们的 Discord 社区！ Bug 和功能请求可以在 Electron 的问题跟踪器中报告。

重要变化​

重点内容​

• 扩展 WebContentsView 以接受预先存在的 webContents 对象 #42319
• 添加了对 NODE_EXTRA_CA_CERTS 的支持。 #41689
• 更新了 window.flashFrame(bool) 以在 macOS 上持续闪烁。 #41391
• 移除了 WebSQL 支持。#41868
• nativeImage.toDataURL 将保留 PNG 颜色空间 #41610
• 扩展 webContents.setWindowOpenHandler 以支持手动创建 BrowserWindow。 #41432

架构（Stack）更新​

• Chromium126.0.6478.36
  • 126 新功能
  • 125 新功能
• Node 20.14.0
  • Node 20.14.0 博客
• V8 12.6

Electron 31 将 Chromium 从 114.0.6367.49 升级到 122.. 0.661.39, Node 从 20.11.2 升级到 20.14.0，V8 从 12.4 升级到 12.6。

新特性​

• 添加 clearData 方法支 Session. #40983
  • 添加参数到 Session.clearData API。 #41355
• 添加了对 navigator.serial 中的服务类ID请求的蓝牙端口的支持。 #41638
• 支持 Node's NODE_EXTRA_CA_CERTS 环境变量. #41689
• 扩展 webContents.setWindowOpenHandler 以支持手动创建 BrowserWindow。 #41432
• 实现了对 web 标准 File System API 的支持。 #41419
• 扩展 WebContentsView 以接受预先存在的 webContents 对象 #42319
• 在 webContents API 上添加了一个新的实例属性 navigationHistory，配合 navigationHistory.getEntryAtIndex 方法，使应用能够检索浏览历史中任何导航条目的 URL 和标题。 #41577 ^{(Also in 29, 30)}

重大更改​

移除: WebSQL 的支持​

Chromium has removed support for WebSQL upstream, transitioning it to Android only. 更多信息，请阅读 Chromium's 移除意图的讨论

行为变更：nativeImage.toDataURL 将保留 PNG 色彩空间。​

PNG 解码器已支持保留颜色空间数据。 从此函数返回的编码数据现在与预期结果匹配。

更多信息，请阅读 crbug.com/332584706。

行为变更：win.flashFrame(bool) 将在 macOS 上持续闪烁 Dock 图标。​

This brings the behavior to parity with Windows and Linux. 之前的行为：第一次调用 flashFrame(true) 只会使 Dock 图标弹跳一次 (使用 NSInformationalRequest level)，调用 flashFrame(false) 不会有任何效果。 现在的行为：持续闪烁，直到调用 flashFrame(false)。 使用了 NSCriticalRequest 级别替换。 如果要明确使用 NSInformationalRequest 使 Dock 图标弹跳一次，仍然可以使用 dock.bounce('informational').

终止对 28.x.y 的支持​

根据项目的支持政策，Electron 28.x.y 已经达到了支持的终点。 我们鼓励开发者将应用程序升级到更新的 Electron 版本。

接下来​

在短期内，您可以期待团队继续专注于跟上构成 Electron 的主要组件的开发，包括 Chromium、Node 和 V8。

您可以在此处找到 Electron 的公开时间表。

有关这些和未来变化的更多信息可在计划的突破性变化页面找到。

Electron 30.0.0 已发布！ 它包括对 Chromium 124.0.6367.49、V8 12.4 和 Node.js 20.11.1 的升级。

Electron 团队很高兴发布了 Electron 30.0.0 ！ 你可以通过 npm install electron@latest 或者从我们的发布网站下载它。 继续阅读此版本的详细信息。

如果您有任何反馈，请在 Twitter 或 Mastodon 上与我们分享，或加入我们的 Discord 社区！ Bug 和功能请求可以在 Electron 的问题跟踪器中报告。

重要变化​

重点内容​

• Windows 现在支持 ASAR 完整性检查 (#40504)
  • 启用ASAR完整性的现有应用程序如果配置不正确，可能无法在Windows上工作。 使用 Electron 打包工具的应用应该升级到 @electron/packager@18.3.1 或 @electron/forge@7.4.0。
  • 查看我们的 ASAR Integrity 教程 以获取更多信息。
• 添加了 WebContentsView 和 BaseWindow 主进程模块，废弃并替换 BrowserView (#35658)
  • BrowserView 现在是 WebContentsView 的一个壳，并且旧的实现已被移除。
  • 查看 我们的 Web Embeds 文档 以便将新的 WebContentsView API 和其他类似 API进行比较。
• 实现了对 File System API 的支持 (#41827)

架构（Stack）更新​

• Chromium 124.0.6367.49
  • Chrome 124 和 DevTools 124 中的新功能
  • Chrome 123 和 DevTools 123 中的新功能
• Node 20.11.1
  • Node 20.11.1 发布说明
• V8 12.4

Electron 30 将 Chromium 从 122.0.6261.39 升级到 124.0.6367.49, Node 从 20.9.0 升级到 20.11.1 以及 V8 从 12.2 升级到 12.4。

新特性​

• 在 webviews 中添加了 transparent 网页偏好设置。 (#40301)
• 在 webContents API 上添加了一个新的实例属性 navigationHistory，配合 navigationHistory.getEntryAtIndex 方法，使应用能够检索浏览历史中任何导航条目的 URL 和标题。 (#41662)
• 新增了 BrowserWindow.isOccluded() 方法，允许应用检查窗口是否被遮挡。 (#38982)
• 为工具进程中 net 模块发出的请求添加了代理配置支持。 (#41417)
• 添加了对 navigator.serial 中的服务类ID请求的蓝牙端口的支持。 (#41734)
• 添加了对 Node.js NODE_EXTRA_CA_CERTS 命令行标志的支持。 (#41822)

重大更改​

行为变更：跨源 iframe 现在使用 Permission Policy 来访问功能。​

跨域 iframe 现在必须通过 allow 属性指定一个给定 iframe 可以访问的功能。

有关更多信息，请参见 文档。

移除：--disable-color-correct-rendering 命令行开关​

此开关从未正式文档化，但无论如何这里都记录了它的移除。 Chromium 本身现在对颜色空间有更好的支持，因此不再需要该标志。

行为变更：BrowserView.setAutoResize 在 macOS 上的行为​

在 Electron 30 中，BrowserView 现在是围绕新的 WebContentsView API 的包装器。

以前，BrowserView API 的 setAutoResize 功能在 macOS 上由 autoresizing 支持，并且在 Windows 和 Linux 上由自定义算法支持。 对于简单的用例，比如使 BrowserView 填充整个窗口，在这两种方法的行为上是相同的。 然而，在更高级的情况下，BrowserViews 在 macOS 上的自动调整大小与在其他平台上的情况不同，因为 Windows 和 Linux 的自定义调整大小算法与 macOS 的自动调整大小 API 的行为并不完全匹配。 自动调整大小的行为现在在所有平台上都标准化了。

如果您的应用使用 BrowserView.setAutoResize 做的不仅仅是使 BrowserView 填满整个窗口，那么您可能已经有了自定义逻辑来处理 macOS 上的这种行为差异。 如果是这样，在 Electron 30 中不再需要这种逻辑，因为自动调整大小的行为是一致的。

移除：WebContents 上 context-menu 的 params.inputFormType 属性​

WebContents 的 context-menu 事件中 params 对象的 inputFormType 属性已被移除。 请改用新的 formControlType 属性。

移除：process.getIOCounters()​

Chromium 已删除对这些信息的访问。

终止对 27.x.y 的支持​

根据项目的支持政策，Electron 27.x.y 已经达到了支持的终点。 我们鼓励开发者将应用程序升级到更新的 Electron 版本。

接下来​

在短期内，您可以期待团队继续专注于跟上构成 Electron 的主要组件的开发，包括 Chromium、Node 和 V8。

您可以在此处找到 Electron 的公开时间表。

有关这些和未来变化的更多信息可在计划的突破性变化页面找到。

我们很高兴地宣布，Electron 已被接受为第 20 届“谷歌代码之夏（GSoC）2024”的指导机构！ Google Summer of Code 是一个全球计划，专注于将新贡献者引入到开源软件的开发中。

欲了解更多计划详情，请查阅 Google 的 Summer of Code 主页。

关于我们​

Electron 是一个 JavaScript 框架，用于使用 Web 技术构建跨平台桌面应用程序。 Electron 的核心框架是一个编译的二进制可执行文件，由 Chromium 和 Node.js 构建，大多以 C++ 编写。

在 Electron 核心之外，我们还致力于各种项目，帮助维持 Electron 组织，例如：

• 用户发行工具（例如，Electron Forge 和 update.electronjs.org）。
• 面向 Electron 开发人员的学习材料（例如 electronjs.org 和 Electron Fiddle）。
• 简化开发者生产力的内部工具（例如，Electron Building Tools 和 Sheriff）。

作为 Summer of Code 贡献者，你将与 Electron 的一些核心贡献者在 github.com/electron 下的众多项目之一上进行合作。

申请前​

如果你不熟悉 Electron，我们会建议你首先阅读文档和在 Electron Fiddle 中尝试示例。

要了解更多有关 Electron 应用程序发布的信息，还可以使用 Electron Forge，创建一个示例应用程序：

npm init electron-app@latest my-app

在稍微熟悉了代码之后，请加入 Electron Discord 服务器.

起草你的提案​

有兴趣与 Electron 合作吗？ 首先，请查看我们准备的 七个项目的议题。 目前，所有列出的议题都接受提案。

你有不同的议题希望我们考虑吗？ 我们也愿意接受不在拟议项目清单上的新议题，但要确保你的方法得到充分的概述和详细说明。 如有疑问，我们建议坚持使用我们列出的想法。

您的申请应包括：

• 你的提案：一份书面文件，详细描述你计划在夏季实现的目标。
• 你作为开发者的背景。 如果你有简历，请附上一份副本。 否则，请告诉我们你过去的技术经验。
  • 在某些领域缺乏经验不会使你失去资格，但它将帮助我们的导师制定一个计划来最好地支持你并确保您的夏季项目取得成功。

这里有关于 Electron 申请提交内容的详细指南。 直接向Google Summer of Code 网站提交提案。 请注意，你应该通过 GSoC 官网提交你的提案，发送邮件到 Electron team 将不会被视为有效提交。

如果你希望获得更多有关提案的指导，或不确定应包含哪些内容，我们还建议你可以参考 Google Summer of Code 官方提案写作建议。

申请在 2024 年 3 月 18 日 开始，于 2024 年 4 月 2 日 停止。

问题?​

如果你有我们在博客文章没有提到的问题，或者对你的提案草案有疑问，请发送电子邮件至 summer-of-code@electronjs.org 或查看 GSoC 常见问题解答!

资源​

• Electron Google Summer of Code 2024 提案列表
• Electron Google Summer of Code 2024 贡献指导
• Google Summer of Code 学生/贡献者指南

Electron 29.0.0 已发布！ 它包括升级 Chromium 122.0.6261.39，和 V8 12.2 以及 Node.js 20.9.2。

Electron 团队很高兴发布了 Electron 29.0.0 ！ 你可以通过 npm install electron@latest 或者从我们的发布网站下载它。 继续阅读此版本的详细信息。

如果您有任何反馈，请在 Twitter 或 Mastodon 上与我们分享，或加入我们的 Discord 社区！ Bug 和功能请求可以在 Electron 的问题跟踪器中报告。

重要变化​

重点内容​

• 添加了一个新的顶级 webUtils 模块，这是一个渲染进程模块，提供与 Web API 对象交互的实用程序层。 模块中第一个可用的 API 是 webUtils.getPathForFile。 Electron 以前的 File.path 扩充偏离了网页标准；这个新的 API 更符合当前的 web 标准行为。

架构（Stack）更新​

• Chromium 122.0.6261.39
  • 新的 Chrome 122 和 DevTools 122
  • 新的 Chrome 121 和 DevTools 121
• Node 20.9.0
  • Node 20.9.0 博文
  • Node 20.0.0 博文
• V8 12.2

Electron 29 将 Chromium 从 120.0.6099.56 升级到 122..0.661.39, Node 从 18.18.2 升级到 20.9.0，V8 从 12.0 升级到 12.2。

新特性​

• 添加了新的 webUtils 模块，一个与 Web API 对象交互的实用程序层，替换 File.path 扩充。 #38776
• 添加 net 模块到 utility process。 #40890
• 添加了一个新的 Electron Fuse， grantFileProtocolExtravileges 让 file:// 协议使其具有更安全和更严格的行为，与 Chromium 相匹配。 #40372
• 在 protocol.registerSchemesAsseged 中添加了一个选项，以允许自定义协议开启 V8 code cache。 #40544
• 迁移 app.{set|get}LoginItemSettings(settings) 以便在 MacOS 13.0+ 上使用 Apple 推荐的新底层框架。 #37244

重大更改​

行为改变：ipcRenderer 不能再通过 contextBridge 发送​

现在通过 contextBridge 传送整个 ipcRenderer 模块作为对象，会在 bridge 的接收方收到一个 空对象。 此更改是为了消除/减轻一种安全隐患。 你不应该直接暴露 bridge 上的 ipcRenderer 或它的方法。 相反，应该提供一个像下面这样的安全包装器：

contextBridge.exposeInMainWorld('app', {
  onEvent: (cb) => ipcRenderer.on('foo', (e, ...args) => cb(args)),
});

移除：app 上的 render-process-crashed 事件​

The renderer-process-crashed event on app has been removed. 改用新的 render-process-gone 事件。

// 移除
app.on('renderer-process-crashed', (event, webContents, killed) => {
  /* ... */
});

// 替换为
app.on('render-process-gone', (event, webContents, details) => {
  /* ... */
});

移除：WebContents 和 <webview> 上的 crashed 事件​

WebContents 和 <webview> 上的 crashed 事件已被移除。 改用新的 render-process-gone 事件。

// 移除
win.webContents.on('crashed', (event, killed) => {
  /* ... */
});
webview.addEventListener('crashed', (event) => {
  /* ... */
});

// 替换为
win.webContents.on('render-process-gone', (event, details) => {
  /* ... */
});
webview.addEventListener('render-process-gone', (event) => {
  /* ... */
});

Removed: gpu-process-crashed event on app​

app 上的 gpu-process-crashed 事件已被移除。 使用新的 child-process-gone 事件代替。

// 移除
app.on('gpu-process-crashed', (event, killed) => {
  /* ... */
});

// 替换为
app.on('child-process-gone', (event, details) => {
  /* ... */
});

终止对 26.x.y 的支持​

根据项目的支持政策，Electron 26.x.y 已经达到了支持的终点。 我们鼓励开发者将应用程序升级到更新的 Electron 版本。

接下来​

您是否知道 Electron 最近添加了社区征求意见 (RFC) 流程？ 如果您想在框架中添加一项功能，RFC 可以成为您与维护者就功能设计展开对话的有用工具。 您还可以查看 PR 中正在讨论的即将发生的更改。 若要了解更多信息，请直接查看我们的 introduction electron/rfcs 博客文章，或查看 electron/rfcs 版本库的 README。

在短期内，您可以期待团队继续专注于跟上构成 Electron 的主要组件的开发，包括 Chromium、Node 和 V8。

您可以在此处找到 Electron 的公开时间表。

有关这些和未来变化的更多信息可在计划的突破性变化页面找到。

Electron 的 API 工作组 正在采用开放的 征求意见 (RFC) 流程来帮助引导更大的变更 到 Electron core。

为什么要使用 RFC？​

简而言之，我们希望顺利完成 Electron core 重大变更的落地过程。

目前，新的代码主要通过 GitHub 上的 issues 和拉取代码合并请求进行变更的。 对于 Electron 的大多数更改，这是一个很好的体系。 许多错误修复、文档更改、 甚至新功能也足够简单，可以通过以下方式异步审查和合并 标准 GitHub 流程。

对于更重大的变化-例如，大型 API 或会影响大多数 Electron 应用程序的破坏性更改，在 构思阶段进行审查是有意义的。

这个过程旨在对公众开放，这也将使得广大 开源社区能够在这些变化落实到 Electron之前，更容易地提供反馈。

它是如何工作的？​

整个 RFC（请求评论）过程托管在 GitHub 上的 electron/rfcs 仓库中。 步骤在仓库的 README 中有详细描述。

简而言之，一旦向 electron/rfcs 仓库提交了 PR，一个 RFC 就被提出了。 一个被提出的 RFC 会变成：

• Active，当 PR 被合并到仓库的 main 分支时，这意味着 Electron 的维护者对在 electron/electron 中实施该提案持开放态度，或者
• Declined，如果 PR 最终被拒绝。

如果实施已经合并到 electron/electron 中，一个激活的 RFC 就被视为 Completed。

谁可以参与？​

Electron 社区中的任何人都可以提交 RFC 或在 electron/rfcs 仓库上留下反馈！

• 要查看活跃 RFC 的列表，请参阅仓库中的 text 文件夹。
• 要对提出的 RFC 留下反馈，请查看开放的 PR 的列表。
• 要提交一个新的 RFC，请查看仓库的 README 和 RFC 模板。

我们希望将这个过程变成一种双向对话，并鼓励社区参与，以便从可能在未来使用这些 API 的 Electron 应用程序中获得多样化的意见。 如果你 对当前提出的 RFC 留下反馈感兴趣，Electron 的维护者们已经创建了 一些：

• Electron C APIs
• Preload Realm for Service Workers

致谢​

Electron 的 RFC 流程借鉴了许多已建立的开源 RFC 流程。 许多想法和主要文案的灵感来源于：

• emberjs/rfcs
• reactjs/rfcs
• rust-lang/rfcs
• tauri-apps/rfcs
• vuejs/rfcs
• yarnpkg/rfcs

今天早些时候，Electron 团队被告知，最近有几个公开的 CVEs 针对几个著名的 Electron 应用程序进行了提交。 这些 CVE 与 Electron 的两个 fuses（保险丝） - runAsNode 和 enableNodeCliInspectArguments - 相关，并错误地声称，如果这些组件没有被积极禁用，远程攻击者能够通过这些组件执行任意代码。

我们认为这些 CVE 并非出于善意提交。 首先，这个声明是不正确的 - 配置并不允许远程代码执行。 其次，尽管拥有漏洞赏金计划，但在这些 CVE 中被点名的公司并没有收到通知。 最后，虽然我们确实相信禁用相关组件可以增强应用程序的安全性，但我们认为这些 CVE 的提交并没有准确反映其严重性。 “Critical”级别是为最高危险的问题保留的，显然这里的情况并非如此。

任何人都可以申请 CVE。 虽然这对软件行业的整体健康有益，但“挖掘 CVEs”来增强单个安全研究员的声誉并没有帮助。

话虽如此，我们理解仅仅是一个带有可怕的 critical 严重性的 CVE 的存在可能会导致用户感到困惑，因此作为一个项目，我们希望提供指导和协助来处理这个问题。

这会给我带来什么影响？​

在审查了 CVEs 之后，Electron 团队认为这些 CVEs 并不是 critical 的。

攻击者需要已经能够在机器上执行任意命令，无论是通过对硬件的物理访问还是通过实现完全的远程代码执行。 这值得重申：所描述的漏洞_要求攻击者已经能够访问被攻击的系统_。

例如，Chrome 在其威胁模型中不考虑本地物理攻击：

我们认为这些攻击超出了 Chrome 的威胁模型范围，因为对于已经能够以你的身份登录你的设备或者能够以你的操作系统用户账户的权限运行软件的恶意用户，Chrome（或任何应用程序）无法进行防御。 这样的攻击者可以修改可执行文件和DLL文件，更改像 PATH 这样的环境变量，更改配置文件，读取你的用户账户所拥有的任何数据，将其通过电子邮件发送给自己等等。 这样的攻击者对你的设备拥有完全的控制权，Chrome 所能做的任何事情都无法提供严格的防御保证。 这个问题不仅仅存在于Chrome - 所有应用程序都必须信任本地物理用户。

利用 CVE 中描述的漏洞，攻击者可以将受影响的应用程序用作具有继承 TCC 权限的通用 Node.js 进程。 因此，如果应用程序例如已被授权访问地址簿，攻击者可以将应用程序作为 Node.js 运行，并执行将继承该地址簿访问权限的任意代码。 这通常被称为“寄生式攻击”。 攻击者通常使用 PowerShell、Bash 或类似工具来运行任意代码。

我是否受到了影响？​

默认情况下，所有发布版本的 Electron 都启用了 runAsNode 和 enableNodeCliInspectArguments 功能。 如果您没有按照 Electron Fuses 文档中描述的方法关闭它们，那么您的应用程序同样容易受到“寄生式攻击”的影响。 再次强调，攻击者需要已经能够在受害者的机器上执行代码和程序。

缓解措施​

减轻这个问题的最简单方法是在您的 Electron 应用程序中禁用 runAsNode fuse。 runAsNode fuse 用于切换是否考虑 ELECTRON_RUN_AS_NODE ` 环境变量。 请参阅 Electron Fuses 文档以获取有关如何切换这些 fuses 的信息。

请注意，如果禁用了这个 fuse，那么主进程中的 process.fork 将无法按预期运行，因为它依赖于这个环境变量来运行。 相反，我们建议您使用实用进程，它适用于许多需要独立的 Node.js 进程的用例（例如 Sqlite 服务器进程或类似情况）。

您可以在我们的安全清单中找到更多关于我们推荐的 Electron 应用程序的安全最佳实践的信息。

Electron 28.0.0 已发布！ 它包括升级 Chromium 120.0.6099.56 和 V8 12.0 以及 Node.js 18.18.2。

Electron 团队很高兴发布了 Electron 28.0.0 ！ 你可以通过 npm install electron@latest 或者从我们的发布网站下载它。 继续阅读此版本的详细信息。

如果您有任何反馈，请在 Twitter 或 Mastodon 上与我们分享，或加入我们的 Discord 社区！ Bug 和功能请求可以在 Electron 的问题跟踪器中报告。

重要变化​

重点内容​

• 实现了对 ECMAScript 模块或 ESM 的支持（什么是 ECMAScript 模块？） 在这里了解更多信息. 这包括在 Electron 本身中支持 ESM，以及诸如 UtilityProcess API 入口点等方面。 详情见我们的 ESM 文档 以获取更多详细信息。
• 除了在 Electron 本身中启用 ESM 支持外，Electron Forge 还支持使用 ESM 来打包、构建和开发 Electron 应用程序。 您可以在 Forge v7.0.0 或更高版本中找到这种支持。

架构（Stack）更新​

• Chromium 120.0.6099.56
  • 新的 Chrome 119 和 DevTools 119
  • 新的 Chrome 120 和 DevTools 120
• Node 18.18.2
  • Node 18.18.0 博文
  • Node 18.18.1 博文
  • Node 18.18.2 博文
• V8 12.0

新特性​

• 启用 ESM 支持。 #37535
  • 更多细节，请见 ESM documentation。
• 为 UtilityProcess API 添加了 ESM 入口点。 #40047
• 添加了几个属性到 display 对象中，包括 detected，maximumCursorSize 和 nativeOrigin。 #40554
• 新增对 Linux 上 ELECTRON_OZONE_PLATFORM_HINT 环境变量的支持。 #39792

重大更改​

行为改变：在宿主 BrowserWindow 中将 WebContents.backgroundThrottling 设置为 false 将影响所有的 WebContents。​

将 WebContents.backgroundThrottling 设置为 false 将禁用由 BrowserWindow 显示的所有 WebContents 的帧节流。

移除: BrowserWindow.setTrafficLightPosition(position)​

已经移除了 BrowserWindow.setTrafficLightPosition(position) 方法，应该改用 BrowserWindow.setWindowButtonPosition(position)方法。新的方法接受 null 作为替换 { x: 0, y: 0 } 的参数，以将位置重置为系统默认值。

// 在 Electron 28 移除
win.setTrafficLightPosition({ x: 10, y: 10 });
win.setTrafficLightPosition({ x: 0, y: 0 });

// 代替为
win.setWindowButtonPosition({ x: 10, y: 10 });
win.setWindowButtonPosition(null);

移除: BrowserWindow.getTrafficLightPosition()​

已经删除了 BrowserWindow.getTrafficLightPosition()，应该使用 BrowserWindow.getWindowButtonPosition() API 代替，当没有自定义位置时，它返回 null 而不是 { x: 0, y: 0 }。

// 在 Electron 28 移除
const pos = win.getTrafficLightPosition();
if (pos.x === 0 && pos.y === 0) {
  // 没有自定义位置
}

// 代替为
const ret = win.getWindowButtonPosition();
if (ret === null) {
  // 没有自定义位置
}

移除: ipcRenderer.sendTo()​

ipcRenderer.sendTo() API 已经被删除。 应该用渲染进程之间的 MessageChannel 来替代它

IpcRendererEvent 的 senderId 和 senderIsMainFrame 属性也已经被移除。

移除: app.runningUnderRosettaTranslation​

app.runningUnderRosettaTranslation 属性已经被移除。 使用 app.runningUnderARM64Translation 代替.

// 移除
console.log(app.runningUnderRosettaTranslation);
// 代替为
console.log(app.runningUnderARM64Translation);

终止对 25.x.y 的支持​

根据项目的支持政策，Electron 25.x.y 已经达到了支持的终点。 我们鼓励开发者将应用程序升级到更新的 Electron 版本。

接下来​

在短期内，您可以期待团队继续专注于跟上构成 Electron 的主要组件的开发，包括 Chromium、Node 和 V8。

您可以在此处找到 Electron 的公开时间表。

有关这些和未来变化的更多信息可在计划的突破性变化页面找到。

回顾 2023 年 Electron 开发者生态系统的改进和变化。

过去几个月里，我们在整个 Electron 生态系统中进行一些优化，以提升 Electron 应用程序的开发者体验！ 这是 Electron HQ 最新增加的项目的快速概述。

Electron Forge 7 及其以后​

Electron Forge 7 — 用于打包和分发 Electron 应用程序的一体化工具的最新主要版本 — 现已发布。

虽然 Forge 6 与 v5 是完全重写的，但 v7 的范围较小，但仍包含一些重大变更。 未来，我们将继续发布 Forge 的主要版本，以便进行必要的重大变更。

欲了解更多详情，请参阅 GitHub 上的完整描述 Forge v7.0.0 更新日志。

重大变更​

• 切换 macOS notarization 工具到 notarytool： 截至2023-11-01。 苹果废弃了 macOS notarization 的传统工具 altool，此次发布将其从 Electron Forge 中完全删除。
• 最小 Node.js 支持增加到 v16.4.0: 在这个版本中，我们已将所需版本的 Node.js 设置为 16.4.0。
• 废弃了对 electron-prebuild 和 electron-prebuild-compile 的支持： electron-prebuild 是 electron npm 模块的原始名称的支持，但在 v1.3.1 中 被 electron 代替了。 electron-prebuild-compile 是一个带有增强开发体验功能的二进制文件的替代方案，但最终作为一个项目被放弃了。

重点内容​

• Google Cloud Storage 发布器: 作为我们推动更好地支持静态自动更新的一部分，Electron Forge 现在支持直接发布到 Google Cloud Storage！
• ESM forge.config.js 支持: Electron Forge 现在支持 ESM forge.config.js 文件。 （附言： 期待在 Electron 28 中支持 ESM entrypoint。）
• Makers 现在可以并行运行： 在 Electron Forge 6 中 Makers 由于 ✨ 遗产 ✨ 原因而顺序运行。 从那时起，我们已经测试了使用并行 Make 步骤的效果，并且没有出现任何负面影响。 当在同一平台上构建多个目标时，你应该会看到加速效果！

静态存储自动更新的改进​

Squirel.Windows 和 Squirrel.Mac 是支持 Electron 的内置 autoUpdater 模块的特定平台更新技术。 两个项目都支持通过两种方法自动更新：

• 一个与 Squirrel 兼容的更新服务器
• 在静态存储提供商上托管的清单 URL (例如 AWS、谷歌云平台、微软 Azure 等)

传统上，更新服务器方法一直被认为是 Electron 应用的推荐方法（并提供了额外的更新逻辑自定义），但它也有一个主要的缺点 — 如果应用是闭源的，它需要维护自己的服务器实例。

另一方面，虽然静态存储方法一直是可行的，但在 Electron 内部没有文档记录，并且在 Electron 工具包中支持不足。

通过 @MarshallOfSound 的杰出工作，无服务器自动应用程序更新已经得到了显著简化：

• Electron Forge 的 Zip 和 Squirrel.Windows 制作工具现在可以配置为输出与 autoUpdater 兼容的更新清单。
• 现在，update-electron-app 的一个新的主要版本（v2.0.0）可以读取这些生成的清单，作为 update.electronjs.org 服务器的替代方案。

一旦你的 Makers 和 Publishers 配置好了并上传更新清单到云文件存储，你只需要几行配置代码就可以启用自动更新。

const { updateElectronApp, UpdateSourceType } = require('update-electron-app');

updateElectronApp({
  updateSource: {
    type: UpdateSourceType.StaticStorage,
    baseUrl: `https://my-manifest.url/${process.platform}/${process.arch}`,
  },
});

@electron/ 扩展宇宙​

Electron 刚开始时，社区发布了许多软件包，以增强开发、包装和分发 Electron 应用的体验。 随着时间的推移，其中许多软件包都被纳入 Electron 的 GitHub 组织，核心团队承担了维护负担。

在2022年，我们开始将所有这些 first-party 工具整合到 npm 的 @electron/ 命名空间下。 此变更意味着以前被称为 electron-foo 的软件包现在在 npm上被称为 @electron/foo，而以前命名为 electron/electron-foo 的仓库现在在 GitHub 上被称为 electron/foo。 这些变化有助于明确划分 first-party 项目和 userland 项目。 这包括许多常用的软件包，例如：

• @electron/asar
• @electron/fuses
• @electron/get
• @electron/notarize
• @electron/osx-sign
• @electron/packager
• @electron/rebuild
• @electron/remote
• @electron/symbolicate-mac
• @electron/universal

从现在开始，我们发布的所有 first-party 软件包都将在 @electron/ 命名空间中。 这条规则有两个例外情况：

• Electron 核心将继续在 electron 软件包下发布。
• Electron Forge 将继续在 @electron-forge/ namespace 下发布其所有的 monorepo 软件包。

介绍 @electron/windows-sign​

从 2023 年 6 月 1日开始，行业标准要求 Windows 代码签名证书的密钥必须存储在符合 FIPS 标准的硬件上。

在实践中，这意味着对于在 CI 环境中构建和签名的应用来说，代码签名变得更加困难，因为许多 Electron 工具使用证书文件和密码作为配置参数，并尝试使用硬编码逻辑从中进行签名。

这种情况对于 Electron 开发人员来说是一个常见的痛点，这就是为什么我们一直在努力寻找一个更好的解决方案，将 Windows 代码签名独立到一个单独的步骤中，类似于 @electron/osx-sign 在 macOS 上的做法。

在未来，我们计划将此软件包完全整合到 Electron Forge 工具链中，但目前它独立存在。 该软件包目前可通过 npm install --save-dev @electron/windows-sign 进行安装，并可通过编程或命令行界面（CLI）进行使用。

请尝试在项目的 issue 跟踪器中给我们反馈！

下一步​

我们将在下个月进入我们每年 12 月安静的时期。 在这样做的同时，我们将考虑如何在 2024 年使 Electron 开发体验更好。

你是否希望看到我们接下来的工作？ 请告诉我们！