Electron 32.0.0 已发布！ 此版本包含了对 Chromium 128.0.6613.36、V8 12.8 和 Node 20.16.0 的升级。

Electron 团队激动地宣布 Electron 32.0.0 发布！您可以通过 `npm install electron@latest` 使用 npm 安装它，或从我们的 发布网站 下载。请继续阅读以获取此版本详情。

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

重要变更​

亮点​

• 在我们的文档中添加了新的 API 版本历史记录，这是由 @piotrpdev 作为 Google Summer of Code 的一部分创建的功能。您可以在 这篇博客文章 中了解更多信息。 #42982
• 从 Web File API 中移除了非标准的 File.path 扩展。#42053
• 在尝试打开被阻止路径下的文件或目录时，Web 文件系统 API 中的失败路径已与上游对齐。 #42993
• 已将以下现有的导航相关 API 添加到 `webcontents.navigationHistory`：`canGoBack`、`goBack`、`canGoForward`、`goForward`、`canGoToOffset`、`goToOffset`、`clear`。先前的导航 API 现已弃用。 #41752

技术栈变更​

• Chromium128.0.6613.36
  • 128 中的新功能
  • 127 中的新功能
• Node 20.16.0
  • Node 20.16.0 博文
• V8 12.8

Electron 32 将 Chromium 从 126.0.6478.36 升级到 128.0.6613.36，Node 从 20.14.0 升级到 20.16.0，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​

Web `File` 对象中非标准的 `path` 属性在 Electron 的早期版本中被添加，作为在渲染器中处理所有事情更为常见时处理原生文件的便捷方法。然而，它偏离了标准，并且也带来了轻微的安全风险，因此从 Electron 32.0 开始，它已被移除，取而代之的是 `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);

行为变更：`userData` 中的 `databases` 目录将在 Electron 32 首次运行时被删除​

如果您在 `app.getPath('userData')` 返回的目录中有名为 `databases` 的目录，它将在 Electron 32 首次运行时被删除。`databases` 目录曾被 WebSQL 使用，而 WebSQL 在 Electron 31 中已被移除。Chromium 现在执行清理操作删除此目录。有关更多信息，请参阅 issue #45396。

终止对 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 20.14.0 的升级。

Electron 团队激动地宣布 Electron 31.0.0 发布！您可以通过 `npm install electron@latest` 使用 npm 安装它，或从我们的 发布网站 下载。请继续阅读以获取此版本详情。

如果您有任何反馈，请在 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

技术栈变更​

• Chromium126.0.6478.36
  • 126 版本新增功能
  • 125 版本新增功能
• Node 20.14.0
  • Node 20.14.0 博文
• V8 12.6

Electron 31 将 Chromium 从 124.0.6367.49 升级到 126.0.6478.36，Node 从 20.11.1 升级到 20.14.0，V8 从 12.4 升级到 12.6。

新特性​

• 向 Session 添加了 clearData 方法。#40983
  • 向 Session.clearData API 添加了 options 参数。#41355
• 添加了对 navigator.serial 中服务类 ID 请求蓝牙端口的支持。#41638
• 增加了对 Node 的 `NODE_EXTRA_CA_CERTS` 环境变量的支持。 #41689
• 扩展了 webContents.setWindowOpenHandler 以支持手动创建 BrowserWindow。#41432
• 实现了对 Web 标准 文件系统 API 的支持。 #41419
• 扩展了 WebContentsView 以接受预先存在的 WebContents 实例。#42319
• 在 webContents API 上添加了一个新的实例属性 `navigationHistory`，并带有 `navigationHistory.getEntryAtIndex` 方法，使应用程序能够检索浏览历史中任何导航条目的 URL 和标题。 #41577 ^{（也包含在 29、30 中）}

破坏性变更​

已移除：WebSQL 支持​

Chromium 已在上游移除了对 WebSQL 的支持，将其迁移到仅限 Android。有关更多信息，请参阅 Chromium 的移除意向讨论。

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

PNG 解码器实现已更改为保留颜色空间数据。此函数返回的编码数据现在与其匹配。

有关更多信息，请参阅 crbug.com/332584706。

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

这将使行为与 Windows 和 Linux 保持一致。之前的行为：第一次 `flashFrame(true)` 只会弹一次 Dock 图标（使用 NSInformationalRequest 级别），而 `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` 使用 npm 安装它，或从我们的 发布网站 下载。请继续阅读以获取此版本详情。

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

重要变更​

亮点​

• ASAR 完整性保险丝现在在 Windows 上受支持 (#40504)
  • 如果配置不正确，现有已启用 ASAR 完整性的应用程序可能无法在 Windows 上运行。使用 Electron 打包工具的应用程序应升级到 @electron/packager@18.3.1 或 @electron/forge@7.4.0。
  • 请查看我们的ASAR 完整性教程以获取更多信息。
• 添加了主进程模块 `WebContentsView` 和 `BaseWindow`，弃用了并替换了 `BrowserView`（#35658）。在 这篇博客文章 中了解更多关于如何从 `BrowserView` 迁移到 `WebContentsView` 的信息。
  • BrowserView 现在是 WebContentsView 的一个垫片，旧的实现已被移除。
  • 请参阅我们的 Web 嵌入文档，了解新的 WebContentsView API 与其他类似 API 的比较。
• 实现了对 文件系统 API 的支持（#41827）

技术栈变更​

• 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。

新特性​

• 为 webview 添加了 transparent webpreference。(#40301)
• 在 webContents API 上添加了一个新的实例属性 `navigationHistory`，并带有 `navigationHistory.getEntryAtIndex` 方法，使应用程序能够检索浏览历史中任何导航条目的 URL 和标题。（#41662）
• 添加了新的 BrowserWindow.isOccluded() 方法，允许应用程序检查遮挡状态。(#38982)
• 为从 utility 进程发出的 net 模块请求添加了代理配置支持。(#41417)
• 在 navigator.serial 中添加了对按服务类 ID 请求蓝牙端口的支持。(#41734)
• 增加了对 Node.js `NODE_EXTRA_CA_CERTS` 命令行标志的支持。（#41822）

破坏性变更​

行为变更：跨域 iframe 现在使用权限策略访问功能​

跨域 iframe 现在必须通过 allow 属性指定可用于给定 iframe 的功能，才能访问它们。

更多信息请参阅文档。

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

这个开关从未被正式记录，但在此仍会注明其移除。Chromium 本身现在对颜色空间有更好的支持，所以应该不再需要这个标志。

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

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

以前，`BrowserView` API 的 `setAutoResize` 函数在 macOS 上基于 autoresizing 实现，而在 Windows 和 Linux 上则基于自定义算法实现。对于使 BrowserView 填充整个窗口等简单用例，这两种方法的行为是相同的。然而，在更高级的情况下，BrowserView 在 macOS 上的 autoresize 方式与其他平台不同，因为 Windows 和 Linux 的自定义重排算法与 macOS 的 autoresizing API 的行为不完全匹配。现在，所有平台上的 autoresize 行为都已标准化。

如果您的应用程序使用 `BrowserView.setAutoResize` 来执行比使 BrowserView 填充整个窗口更复杂的任务，那么您可能已经采取了自定义逻辑来处理 macOS 上的这种行为差异。如果是这样，在 Electron 30 中，由于 autoresize 行为的一致性，将不再需要这些逻辑。

移除：`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 已被接纳为 2024 年第 20 届 Google Summer of Code (GSoC) 的指导组织！Google Summer of Code 是一个旨在吸引新贡献者进入开源软件开发的全球性项目。

有关该项目的更多详情，请查看谷歌的 Summer of Code 主页。

关于我们​

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

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

• 面向最终用户的分发工具（例如 Electron Forge 和 update.electronjs.org）。
• 为 Electron 开发者提供的学习资料（例如 electronjs.org 和 Electron Fiddle）。
• 内部工具以提高开发者效率（例如 Electron Build 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 门户提交提案。请注意，通过电子邮件发送给 Electron 团队而不是通过申请门户提交的提案将不被视为最终提交。

如果您想获得更多关于提案的指导，或者不确定应包含哪些内容，我们也建议您遵循 Google Summer of Code 官方提案写作建议。

申请于 2024 年 3 月 18 日 开放，并于 2024 年 4 月 2 日 截止。

有疑问？​

如果您有我们未在博客文章中解答的问题，或对您的提案草稿有疑问，请发送电子邮件至 summer-of-code@electronjs.org，或查看 GSoC FAQ！

资源​

• 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.0 的升级。

Electron 团队激动地宣布 Electron 29.0.0 发布！您可以通过 `npm install electron@latest` 使用 npm 安装它，或从我们的 发布网站 下载。请继续阅读以获取此版本详情。

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

重要变更​

亮点​

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

技术栈变更​

• 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.6261.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，`grantFileProtocolExtraPrivileges`，它将 `file://` 协议配置为更安全、更严格的行为，与 Chromium 保持一致。 #40372
• 在 protocol.registerSchemesAsPrivileged 中添加了一个选项，允许在自定义方案中使用 V8 代码缓存。 #40544
• 在 macOS 13.0+ 上，已将 app.{set|get}LoginItemSettings(settings) 迁移到使用 Apple 新推荐的底层框架。 #37244

破坏性变更​

行为变更：`ipcRenderer` 不能再通过 `contextBridge` 传递​

尝试将整个 `ipcRenderer` 模块作为对象通过 `contextBridge` 传递，现在将在桥的接收端得到一个空对象。此更改是为了移除/缓解一个安全隐患。您不应直接通过桥暴露 ipcRenderer 或其方法。而是提供一个安全的包装器，如下所示：

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

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

app 上的 renderer-process-crashed 事件已被移除。请改用新的 render-process-gone 事件。

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

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

移除：`WebContents` 和 `` 上的 `crashed` 事件​

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

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

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

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

app 上的 gpu-process-crashed 事件已被移除。请改用新的 child-process-gone 事件。

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

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

26.x.y 版本停止支持​

根据项目的 支持策略，Electron 26.x.y 已达到支持终点。鼓励开发者和应用程序升级到新版本的 Electron。

下一步计划​

您知道 Electron 最近添加了社区的“征求意见”（RFC）流程吗？如果您想为框架添加功能，RFC 可以成为与维护者就其设计展开对话的有用工具。您也可以在 Pull Requests 中查看即将进行的更改。要了解更多信息，请查看我们的 “Introducing electron/rfcs”博客文章，或直接查看 electron/rfcs 存储库的 README。

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

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

有关未来变更的更多信息，请参阅计划中的破坏性变更页面。

Electron 的 API 工作组 正在采用开放的 **征求意见（RFC）** 流程，以帮助引导对 Electron 核心的较大更改。

为什么需要 RFC？​

简而言之，我们希望能够顺利地将重大变更引入 Electron 核心。

目前，新的代码更改主要通过 GitHub 上的 issues 和 pull requests 进行讨论。对于 Electron 的大多数更改，这是一个很好的系统。许多 Bug 修复、文档更改甚至新功能都足够简单，可以通过标准的 GitHub 流程进行异步审查和合并。

对于更重大的变更——例如，大型 API 接口或会影响大多数 Electron 应用的破坏性变更——在编写大部分代码之前，于构思阶段进行审查是很有意义的。

此流程被设计为向公众开放，这也将使广大的开源社区更容易在潜在变更进入 Electron 之前对其提供反馈。

它是如何运作的？​

整个 RFC 流程位于 GitHub 上的 electron/rfcs 存储库中。步骤在存储库 README 中有详细描述。

简而言之，一旦向 electron/rfcs 仓库提交了 PR，一个 RFC 就进入了提案（Proposed）阶段。一个提案中的 RFC 会进入

• 激活（Active）状态，当该 PR 被合并到仓库的 main 分支时，这意味着 Electron 维护者们同意在 electron/electron 中实现该提案，或者
• 拒绝（Declined）状态，如果该 PR 最终被拒绝。

一个激活状态的 RFC 在其实现被合并到 electron/electron 后，将进入完成（Completed）状态。

谁可以参与？​

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

• 要查看激活状态的 RFC 列表，请参考仓库中的 text 文件夹。
• 要对提案中的 RFC 留下反馈，请查看开放的 PR 列表。
• 要提交新的 RFC，请查看存储库的 README 和 RFC 模板。

我们希望使这个过程成为双向对话，并鼓励社区参与，以获得未来可能使用这些 API 的 Electron 应用程序的各种意见。如果您有兴趣对当前提议的 RFC 发表反馈，Electron 维护者已经创建了一些。

• Electron C API
• 用于 Service Worker 的 Preload Realm

致谢​

Electron 的 RFC 流程是基于许多已建立的开源 RFC 流程建模的。许多想法的灵感和主要文案部分都来自于：

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

今天早些时候，Electron 团队收到了关于最近针对几个知名 Electron 应用程序提交的几项公开 CVE 的警报。这些 CVE 与 Electron 的两个 fuses 相关——`runAsNode` 和 `enableNodeCliInspectArguments`——并错误地声称远程攻击者可以在未主动禁用这些组件的情况下通过它们执行任意代码。

我们认为这些 CVE 不是善意提交的。首先，这种说法是不正确的——该配置*不*允许远程代码执行。其次，尽管有漏洞赏金计划，但在此类 CVE 中被点名的公司并未收到通知。最后，虽然我们认为禁用相关组件可以增强应用程序安全性，但我们并不认为这些 CVE 被以正确的严重性级别提交。“Critical”仅用于最危险的问题，而这里的情况远非如此。

任何人都可以请求 CVE。虽然这有助于整个软件行业的健康发展，但为了提升某个安全研究员的声誉而“刷 CVE”则无益。

尽管如此，我们理解带有令人担忧的critical严重性的 CVE 的存在可能会导致最终用户混淆，因此作为项目方，我们希望就如何处理此问题提供指导和帮助。

这可能如何影响我？​

经过对 CVE 的审查，Electron 团队认为这些 CVE 并非关键性问题。

攻击者需要已经能够在机器上执行任意命令，无论是通过物理访问硬件，还是通过完全远程代码执行。需要再次强调：描述中的漏洞*要求攻击者已经能够访问被攻击的系统*。

例如，Chrome 不认为物理本地攻击在其威胁模型中。

我们认为这些攻击超出了 Chrome 的威胁模型，因为 Chrome（或任何应用程序）都无法防御能够以您的身份登录您的设备，或能够以您的操作系统用户帐户特权运行软件的恶意用户。这样的攻击者可以修改可执行文件和 DLL，更改环境变量（如 `PATH`），修改配置文件，读取您的用户帐户拥有的任何数据，并将其发送给自己等。这样的攻击者可以完全控制您的设备，而 Chrome 无法提供任何严肃的防御保证。这个问题并非 Chrome 特有——所有应用程序都必须信任物理本地用户。

CVE 中描述的漏洞允许攻击者将受影响的应用程序用作具有继承权限的通用 Node.js 进程。例如，如果应用程序已被授予访问通讯录的权限，攻击者就可以运行该应用程序作为 Node.js 并执行任意代码，这些代码将继承该通讯录访问权限。这通常被称为“living off the land”攻击。攻击者通常使用 PowerShell、Bash 或类似工具来运行任意代码。

我受到影响吗？​

默认情况下，所有发布的 Electron 版本都启用了 `runAsNode` 和 `enableNodeCliInspectArguments` 功能。如果您尚未按照 Electron Fuses 文档 中的描述将其禁用，那么您的应用程序同样容易受到“living off the land”攻击。再次强调，攻击者需要*已经*能够在受害者机器上执行代码和程序。

缓解措施​

缓解此问题的最简单方法是在您的 Electron 应用程序中禁用 `runAsNode` fuse。`runAsNode` fuse 控制是否遵守 `ELECTRON_RUN_AS_NODE` 环境变量。请参阅 Electron Fuses 文档 以获取有关如何切换这些 fuse 的信息。

请注意，如果此 fuse 被禁用，则主进程中的 `process.fork` 将无法按预期工作，因为它依赖于此环境变量才能运行。我们建议您使用 Utility Processes，它们适用于许多需要独立 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` 使用 npm 安装它，或从我们的 发布网站 下载。请继续阅读以获取此版本详情。

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

重要变更​

亮点​

• 实现了对 ECMAScript 模块或 ESM 的支持（ECMAScript 模块是什么？了解更多。这包括对 Electron 本身以及 `UtilityProcess` API 入口点等区域的 ESM 支持。有关更多详细信息，请参阅我们的 ESM 文档。
• 除了在 Electron 本身中启用 ESM 支持外，Electron Forge 还支持使用 ESM 来打包、构建和开发 Electron 应用程序。您可以在 Forge v7.0.0 或更高版本中找到此支持。

技术栈变更​

• 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 文档。
• 为 UtilityProcess API 添加了 ESM 入口。 #40047
• 在 `display` 对象中添加了几个属性，包括 `detected`、`maximumCursorSize` 和 `nativeOrigin`。 #40554
• 在 Linux 上增加了对 ELECTRON_OZONE_PLATFORM_HINT 环境变量的支持。 #39792

破坏性变更​

行为变更：`WebContents.backgroundThrottling` 设置为 false 会影响主机 `BrowserWindow` 中的所有 `WebContents`​

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

移除：`BrowserWindow.setTrafficLightPosition(position)`​

已移除 `BrowserWindow.setTrafficLightPosition(position)`，应改用 `BrowserWindow.setWindowButtonPosition(position)` API，该 API 接受 `null` 而不是 `{ x: 0, y: 0 }` 来将位置重置为系统默认值。

// Removed in Electron 28
win.setTrafficLightPosition({ x: 10, y: 10 });
win.setTrafficLightPosition({ x: 0, y: 0 });

// Replace with
win.setWindowButtonPosition({ x: 10, y: 10 });
win.setWindowButtonPosition(null);

移除：`BrowserWindow.getTrafficLightPosition()`​

已移除 `BrowserWindow.getTrafficLightPosition()`，应改用 `BrowserWindow.getWindowButtonPosition()` API，当没有自定义位置时，该 API 返回 `null` 而不是 `{ x: 0, y: 0 }`。

// Removed in Electron 28
const pos = win.getTrafficLightPosition();
if (pos.x === 0 && pos.y === 0) {
  // No custom position.
}

// Replace with
const ret = win.getWindowButtonPosition();
if (ret === null) {
  // No custom position.
}

已移除: ipcRenderer.sendTo()​

已移除 `ipcRenderer.sendTo()` API。应使用在渲染器之间设置 `MessageChannel` 来替换它。

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

移除：`app.runningUnderRosettaTranslation`​

app.runningUnderRosettaTranslation 属性已被移除。 请改用 app.runningUnderARM64Translation。

// Removed
console.log(app.runningUnderRosettaTranslation);
// Replace with
console.log(app.runningUnderARM64Translation);

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

根据项目的 支持策略，Electron 25.x.y 已达到支持终点。鼓励开发者和应用程序升级到新版本的 Electron。

下一步计划​

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

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

有关未来变更的更多信息，请参阅计划中的破坏性变更页面。

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

在过去的几个月里，我们一直在 Electron 生态系统中酝酿一些变化，以增强 Electron 应用程序的开发者体验！以下是来自 Electron 总部的最新补充内容的快速概要。

Electron Forge 7 及未来版本​

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

虽然 Forge 6 是对 v5 的完全重写，但 v7 的范围更小，但仍包含一些破坏性变更。未来，我们将继续在需要进行破坏性变更时发布 Forge 的主版本。

更多详情，请查看 GitHub 上的完整 Forge v7.0.0 更新日志。

破坏性变更​

• 切换到使用 notarytool 进行 macOS 公证： 自 2023-11-01 起，Apple 停用了用于 macOS 公证的旧版 altool，此版本将其从 Electron Forge 中完全移除。
• 最低 Node.js 版本提升至 v16.4.0： 在此版本中，我们将最低要求的 Node.js 版本设置为 16.4.0。
• 已弃用 `electron-prebuilt` 和 `electron-prebuilt-compile` 的支持：`electron-prebuilt` 是 Electron npm 模块的原始名称，但在 v1.3.1 中被 `electron` 取代。`electron-prebuilt-compile` 是其二进制文件的替代品，具有增强的 DX 功能，但最终被放弃作为一个项目。

亮点​

• Google Cloud Storage Publisher：作为我们致力于更好地支持静态自动更新的一部分，Electron Forge 现在支持直接发布到 Google Cloud Storage！
• ESM forge.config.js 支持：Electron Forge 现在支持 ESM `forge.config.js` 文件。（顺便说一下，敬请期待 Electron 28 中的 ESM 入口点支持。）
• Makers 现在并行运行：在 Electron Forge 6 中，Makers 因 ✨ 历史原因 ✨ 按顺序运行。从那时起，我们已测试了 Make 步骤的并行化，没有产生任何不良影响，因此您在为同一平台构建多个目标时应该会看到速度提升！

更好的静态存储自动更新​

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

• 一个兼容 Squirrel 的更新服务器
• 一个托管在静态存储提供商（例如 AWS、Google Cloud Platform、Microsoft Azure 等）上的清单 URL

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

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

在 @MarshallOfSound 的出色工作下，无服务器自动应用更新的流程得到了极大的简化

• Electron Forge 的 Zip 和 Squirrel.Windows maker 现在可以配置为输出与 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 年，我们开始将所有这些第一方工具统一到 npm 上的 `@electron/` 命名空间下。此更改意味着以前名为 `electron-foo` 的软件包现在在 npm 上为 `@electron/foo`，而以前命名为 `electron/electron-foo` 的存储库现在在 GitHub 上为 `electron/foo`。这些更改有助于清晰地区分第一方项目和用户域项目。这包括许多常用软件包，例如

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

未来，我们发布的所有第一方包也将在 @electron/ 命名空间下。此规则有两个例外

• Electron 核心将继续在 electron 包下发布。
• Electron Forge 将继续将其所有 monorepo 包发布在 @electron-forge/ 命名空间下。

介绍 @electron/windows-sign​

从 2023-06-01 开始，行业标准开始要求将 Windows 代码签名证书的密钥存储在符合 FIPS 标准的硬件上。

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

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

未来，我们计划将此软件包完全集成到 Electron Forge 工具链中，但目前它独立存在。该软件包目前可以通过 `npm install --save-dev @electron/windows-sign` 安装，并可用于编程或通过 CLI。

请试用它，并在仓库的问题跟踪器中给我们反馈！

下一步是什么？​

下个月我们将进入我们年度的十二月静默期。在此期间，我们将思考如何在 2024 年让 Electron 的开发体验变得更好。

你希望我们接下来做些什么吗？告诉我们吧！

Electron 项目将在 2023 年 12 月暂停，并于 2024 年 1 月恢复全面开发。

来自 GIPHY

12 月份保持不变的事项​

1. 零日漏洞和其他与主要安全相关的版本将根据需要发布。安全事件应通过 SECURITY.md 报告。
2. 行为准则的报告和管理工作将继续进行。

12 月份会有所不同的事项​

1. Electron 28.0.0 将于 12 月 5 日发布。在 Electron 28 之后，12 月将不再有新的稳定版发布。
2. 12 月的最后两周将不会有 Nightly 和 Alpha 版本发布。
3. 除少数例外情况外，不会进行 Pull Request 的审查或合并。
4. 任何代码仓库的 Issue Tracker 都不会有更新。
5. 维护者不会在 Discord 上提供调试帮助。
6. 社交媒体内容将暂停更新。

未来计划​

这是我们第三年执行静默期实验，到目前为止，我们在平衡一个月的休息时间与之后维持正常发布周期方面取得了很大成功。因此，我们决定将此作为我们未来发布日历的常规部分。我们仍然会在每年最后一个稳定版本中添加一个提醒。

2024 年再见！