跳到主要内容

Electron 32.0.0

·5 分钟阅读

Electron 32.0.0 已发布!它包括 Chromium 128.0.6613.36、V8 12.8 和 Node 20.16.0 的升级。


Electron 团队很高兴地宣布 Electron 32.0.0 发布!您可以通过 npm 使用 npm install electron@latest 安装它,或者从我们的发布网站下载。请继续阅读以了解此版本的详细信息。

如果您有任何反馈,请通过TwitterMastodon 与我们分享,或加入我们的社区 Discord!Bug 和功能请求可以在 Electron 的问题追踪器中报告。

值得注意的变更

亮点

  • 在我们的文档中添加了新的 API 版本历史记录,这是 @piotrpdev 作为 Google 编程之夏项目的一部分创建的功能。您可以在这篇博客文章中了解更多信息。#42982
  • 从 Web File API 中移除了非标准的 File.path 扩展。#42053
  • 在尝试打开被阻止路径中的文件或目录时,Web 文件系统 API 中的失败路径与上游保持一致。#42993
  • 将以下现有导航相关 API 添加到 webcontents.navigationHistorycanGoBackgoBackcanGoForwardgoForwardcanGoToOffsetgoToOffsetclear。以前的导航 API 现已弃用。#41752

技术栈变更

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
  • cumulativeCPUUsage 属性添加到 CPUUsage 结构中,该属性返回自进程启动以来使用的 CPU 时间总秒数。#41819
  • 将以下现有导航相关 API 添加到 webContents.navigationHistorycanGoBackgoBackcanGoForwardgoForwardcanGoToOffsetgoToOffsetclear#41752
  • 扩展了 WebContentsView 以接受预先存在的 webContents 对象。#42086
  • nativeTheme 添加了一个新属性 prefersReducedTransparency,它指示用户是否通过系统辅助功能设置选择了降低 OS 级别的透明度。#43137
  • 在文件系统访问 API 中,当尝试在被阻止的路径中打开文件或目录时,失败路径与上游保持一致。#42993
  • 在 Linux 上启用了 Windows Control Overlay 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 上的 clearHistorycanGoBackgoBackcanGoForwardgoForwardgoToIndexcanGoToOffsetgoToOffset

WebContents 实例上的导航相关 API 现已弃用。这些 API 已移至 WebContentsnavigationHistory 属性,以提供更结构化和直观的界面来管理导航历史记录。

// 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 将被删除

如果您在 app.getPath('userData') 返回的目录中有一个名为 databases 的目录,它将在 Electron 32 首次运行时被删除。databases 目录曾被 WebSQL 使用,该功能在 Electron 31 中被移除。Chromium 现在执行一项清理操作,会删除此目录。请参阅 问题 #45396

29.x.y 版本停止支持

根据项目的支持策略,Electron 29.x.y 已达到停止支持的生命周期。建议开发者和应用程序升级到更新的 Electron 版本。

E32 (24 年 8 月)E33 (24 年 10 月)E34 (25 年 1 月)
32.x.y33.x.y34.x.y
31.x.y32.x.y33.x.y
30.x.y31.x.y32.x.y

后续计划

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

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

有关未来变更的更多信息,请参阅计划的重大变更页面。

Electron 31.0.0

·4 分钟阅读

Electron 31.0.0 已发布!它包括 Chromium 126.0.6478.36、V8 12.6 和 Node 20.14.0 的升级。


Electron 团队很高兴地宣布 Electron 31.0.0 发布!您可以通过 npm 使用 npm install electron@latest 安装它,或者从我们的发布网站下载。请继续阅读以了解此版本的详细信息。

如果您有任何反馈,请通过TwitterMastodon 与我们分享,或加入我们的社区 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

技术栈变更

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 版本。

E31 (24 年 6 月)E32 (24 年 8 月)E33 (24 年 10 月)
31.x.y32.x.y33.x.y
30.x.y31.x.y32.x.y
28.x.y29.x.y31.x.y

后续计划

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

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

有关未来变更的更多信息,请参阅计划的重大变更页面。

Electron 30.0.0

·5 分钟阅读

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


Electron 团队很高兴地宣布 Electron 30.0.0 发布!您可以通过 npm 使用 npm install electron@latest 安装它,或者从我们的发布网站下载。请继续阅读以了解此版本的详细信息。

如果您有任何反馈,请通过TwitterMastodon 与我们分享,或加入我们的社区 Discord!Bug 和功能请求可以在 Electron 的问题追踪器中报告。

值得注意的变更

亮点

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

技术栈变更

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 webpreference。 (#40301)
  • 在 webContents API 上添加了一个新的实例属性 navigationHistory,其中包含 navigationHistory.getEntryAtIndex 方法,使应用程序能够检索浏览历史记录中任何导航条目的 URL 和标题。 (#41662)
  • 添加了新的 BrowserWindow.isOccluded() 方法,允许应用程序检查遮挡状态。 (#38982)
  • 添加了对实用进程中使用 net 模块发出的请求的代理配置支持。 (#41417)
  • 添加了在 navigator.serial 中按服务类 ID 请求蓝牙端口的支持。 (#41734)
  • 添加了对 Node.js NODE_EXTRA_CA_CERTS CLI 标志的支持。 (#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 填充整个窗口,这两种方法的行为是相同的。但是,在更高级的用例中,BrowserViews 在 macOS 上的自动调整大小与在其他平台上的自动调整大小不同,因为 Windows 和 Linux 的自定义调整大小算法与 macOS 的自动调整大小 API 的行为不完全匹配。现在,自动调整大小行为在所有平台上都标准化了。

如果您的应用程序使用 BrowserView.setAutoResize 进行比使 BrowserView 填充整个窗口更复杂的操作,那么您可能已经有自定义逻辑来处理 macOS 上的这种行为差异。如果是这样,在 Electron 30 中将不再需要该逻辑,因为自动调整大小行为是一致的。

已移除:WebContentscontext-menu 事件的 params.inputFormType 属性

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

已移除:process.getIOCounters()

Chromium 已移除对该信息的访问。

27.x.y 版本停止支持

根据项目的支持策略,Electron 27.x.y 已达到停止支持的生命周期。建议开发者和应用程序升级到更新的 Electron 版本。

E30 (24 年 4 月)E31 (24 年 6 月)E32 (24 年 8 月)
30.x.y31.x.y32.x.y
29.x.y30.x.y31.x.y
28.x.y29.x.y30.x.y

后续计划

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

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

有关未来变更的更多信息,请参阅计划的重大变更页面。

Google 编程之夏 2024

·4 分钟阅读

我们很高兴地宣布 Electron 已被接受成为 Google 编程之夏 (GSoC) 2024 年第 20 届的指导组织!Google 编程之夏是一项全球性计划,旨在吸引新的贡献者参与开源软件开发。

有关更多计划详情,请查看 Google 的编程之夏主页

关于我们

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

除了 Electron 核心之外,我们还致力于各种项目以帮助维护 Electron 组织,例如

作为编程之夏的贡献者,您将与 Electron 的一些核心贡献者在 github.com/electron 旗下的众多项目之一上进行协作。

申请前

如果您对 Electron 不太熟悉,我们建议您从阅读文档并尝试 Electron Fiddle 中的示例开始。

要了解更多关于 Electron 应用程序分发的信息,您还可以通过创建示例应用程序来使用 Electron Forge

npm init electron-app@latest my-app

在熟悉代码后,请加入 Electron Discord 服务器上的对话。

信息

如果这是您第一次参加 Google 编程之夏,或者您是开源领域的新手,我们建议您在与社区互动之前,先阅读 Google 的贡献者指南

起草您的提案

有兴趣与 Electron 合作吗?首先,请查看我们准备的七个项目提案草稿。所有列出的想法目前都开放接受提案。

有不同的想法希望我们考虑吗?我们也欢迎接受未在建议项目列表中的新想法,但请确保您的方案经过彻底的概述和详细说明。如有疑问,我们建议您坚持我们列出的想法。

您的申请应包括

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

此处是关于 Electron 申请需要提交内容的详细指南。请将提案直接提交到 Google 编程之夏门户。请注意,通过电子邮件发送给 Electron 团队而非通过申请门户提交的提案将不被视为最终提交。

如果您想获得更多关于提案的指导,或者不确定要包含什么,我们也建议您遵循此处提供的官方 Google 编程之夏提案撰写建议

申请于2024 年 3 月 18 日开放,并于2024 年 4 月 2 日关闭。

信息

我们的 2022 年 Google 编程之夏实习生 @aryanshridhar 表现出色!如果您想了解 Aryan 在 Electron 实习期间的工作,可以在 2022 年 GSoC 计划档案中阅读他的报告。

有问题?

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

资源

Electron 29.0.0

·5 分钟阅读

Electron 29.0.0 已发布!它包括 Chromium 122.0.6261.39、V8 12.2 和 Node.js 20.9.0 的升级。


Electron 团队很高兴地宣布 Electron 29.0.0 发布!您可以通过 npm 使用 npm install electron@latest 安装它,或者从我们的发布网站下载。请继续阅读以了解此版本的详细信息。

如果您有任何反馈,请通过TwitterMastodon 与我们分享,或加入我们的社区 Discord!Bug 和功能请求可以在 Electron 的问题追踪器中报告。

值得注意的变更

亮点

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

技术栈变更

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 模块添加到 实用进程#40890
  • 添加了一个新的 Electron FusegrantFileProtocolExtraPrivileges,它选择 file:// 协议以更安全和限制性的行为,与 Chromium 匹配。#40372
  • protocol.registerSchemesAsPrivileged 中添加了一个选项,允许在自定义方案中使用 V8 代码缓存。#40544
  • 在 macOS 13.0+ 上将 app.{set|get}LoginItemSettings(settings) 迁移到使用 Apple 新推荐的底层框架。#37244

重大变更

行为变更:ipcRenderer 不能再通过 contextBridge 发送

尝试通过 contextBridge 将整个 ipcRenderer 模块作为对象发送,现在将在桥的接收端产生一个空对象。此更改是为了移除/缓解一个安全隐患。您不应直接通过桥暴露 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<webview> 上的 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 版本。

E29 (24 年 2 月)E30 (24 年 4 月)E31 (24 年 6 月)
29.x.y30.x.y31.x.y
28.x.y29.x.y30.x.y
27.x.y28.x.y29.x.y

后续计划

您知道 Electron 最近添加了社区征求意见稿 (RFC) 流程吗?如果您想向框架添加功能,RFC 是一种与维护者就其设计展开对话的有用工具。您还可以查看正在讨论的拉取请求中即将进行的更改。要了解更多信息,请查看我们的Introducing electron/rfcs 博客文章,或直接查看 electron/rfcs 仓库的 README。

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

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

有关未来变更的更多信息,请参阅计划的重大变更页面。

推出 electron/rfcs

·4 分钟阅读

Electron 的 API 工作组正在采用开放的征求意见稿 (RFC) 流程,以帮助引导 Electron 核心的重大更改。

为什么是 RFCs?

简而言之,我们希望简化 Electron 核心中重大更改的落地过程。

目前,新的代码更改主要通过 GitHub 上的问题和拉取请求进行讨论。对于 Electron 的大多数更改来说,这是一个很好的系统。许多错误修复、文档更改,甚至新功能都足够直接,可以通过标准的 GitHub 流程异步审查和合并。

对于更重要的更改——例如,大型 API 表面或会影响大多数 Electron 应用程序的重大更改——在大部分代码编写之前在构思阶段进行审查是合理的。

此过程旨在向公众开放,这也将使整个开源社区更容易在潜在更改落地 Electron 之前提供反馈。

它是如何运作的?

整个 RFC 流程都在 GitHub 上的 electron/rfcs 仓库中。具体步骤在仓库的 README 中有详细描述。

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

  • 当 PR 合并到仓库的 main 分支时,该 RFC 变为活跃,这意味着 Electron 维护者同意在 electron/electron 中实现,或者
  • 如果 PR 最终被拒绝,则为已拒绝
信息

要使 RFC 变为活跃,该 PR 必须获得至少 2 名 API 工作组成员的批准。在合并之前,RFC 应同步呈现并获得至少三分之二工作组成员的法定人数的一致接受。如果达成共识,将触发为期一个月的最终评论期,之后 PR 将被合并。

如果实现已合并到 electron/electron 中,则活跃的 RFC 变为已完成

谁可以参与?

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

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

致谢

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

关于 "runAsNode" CVEs 的声明

·4 分钟阅读

今天早些时候,Electron 团队收到警报,称最近针对一些著名的 Electron 应用程序提交了几份公开 CVE。这些 CVE 与 Electron 的两个熔断器——runAsNodeenableNodeCliInspectArguments 相关,并错误地声称如果这些组件未主动禁用,远程攻击者可以通过它们执行任意代码。

我们不认为这些 CVE 是善意提交的。首先,该声明不正确——该配置支持远程代码执行。其次,这些 CVE 中点名的公司尽管有漏洞奖励计划,但并未收到通知。最后,尽管我们确实认为禁用相关组件可以增强应用程序安全性,但我们不认为这些 CVE 的严重性被正确评定。“严重”级别保留给最高危险的问题,而这里显然不是这种情况。

任何人都可以请求 CVE。虽然这有利于软件行业的整体健康,但“刷 CVE”以提升单一安全研究员的声誉是没有帮助的。

尽管如此,我们理解带有可怕的 critical 严重性级别的 CVE 的存在可能会导致最终用户混淆,因此作为一个项目,我们希望就如何处理这个问题提供指导和帮助。

这可能对我有什么影响?

在审查了 CVE 后,Electron 团队认为这些 CVE 并非“严重”。

攻击者需要已经能够在机器上执行任意命令,无论是通过物理访问硬件还是已经实现了完全的远程代码执行。这需要重复强调:所述的漏洞要求攻击者已经可以访问被攻击的系统

例如,Chrome 不考虑其威胁模型中的物理本地攻击

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

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

我是否受到影响?

默认情况下,所有已发布的 Electron 版本都启用了 runAsNodeenableNodeCliInspectArguments 功能。如果您没有按照 Electron Fuses 文档中所述将其关闭,您的应用程序同样容易被用作“利用现有资源”攻击。再次强调,攻击者必须已经能够在受害者的机器上执行代码和程序。

缓解措施

缓解此问题最简单的方法是在 Electron 应用程序中禁用 runAsNode 熔断器。runAsNode 熔断器控制是否尊重 ELECTRON_RUN_AS_NODE 环境变量。有关如何切换这些熔断器的信息,请参阅Electron Fuses 文档

请注意,如果禁用此熔断器,则主进程中的 process.fork 将无法按预期运行,因为它依赖于此环境变量才能运行。相反,我们建议您使用 实用程序进程,它适用于许多需要独立 Node.js 进程的用例(如 Sqlite 服务器进程或类似场景)。

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

Electron 28.0.0

·4 分钟阅读

Electron 28.0.0 已发布!它包括 Chromium 120.0.6099.56、V8 12.0 和 Node.js 18.18.2 的升级。


Electron 团队很高兴地宣布 Electron 28.0.0 发布!您可以通过 npm 使用 npm install electron@latest 安装它,或者从我们的发布网站下载。请继续阅读以了解此版本的详细信息。

如果您有任何反馈,请通过TwitterMastodon 与我们分享,或加入我们的社区 Discord!Bug 和功能请求可以在 Electron 的问题追踪器中报告。

值得注意的变更

亮点

技术栈变更

新功能

  • Electron 28 将 Chromium 从 118.0.5993.88 升级到 120.0.6099.56,将 Node 从 18.17.1 升级到 18.18.2,将 V8 从 11.8 升级到 12.0
    • 启用了 ESM 支持。#37535
  • 有关更多详细信息,请参阅 ESM 文档
  • UtilityProcess API 添加了 ESM 入口点。#40047
  • display 对象添加了几个属性,包括 detectedmaximumCursorSizenativeOrigin#40554

重大变更

添加了对 Linux 上 ELECTRON_OZONE_PLATFORM_HINT 环境变量的支持。#39792

行为变更:WebContents.backgroundThrottling 设置为 false 会影响主机 BrowserWindow 中所有 WebContents

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

已移除:BrowserWindow.setTrafficLightPosition(position)

// 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.setTrafficLightPosition(position) 已移除,应改用 BrowserWindow.setWindowButtonPosition(position) API,该 API 接受 null 而不是 { x: 0, y: 0 } 来将位置重置为系统默认值。

已移除:BrowserWindow.getTrafficLightPosition()

// 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.
}

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

已移除:ipcRenderer.sendTo()

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

IpcRendererEventsenderIdsenderIsMainFrame 属性也已移除。

已移除:app.runningUnderRosettaTranslation

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

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

25.x.y 版本停止支持

根据项目的支持策略,Electron 25.x.y 已达到停止支持的生命周期。建议开发者和应用程序升级到更新的 Electron 版本。E29 (24 年 2 月)E30 (24 年 4 月)
28.x.y29.x.y30.x.y
27.x.y28.x.y29.x.y
E28 (23 年 12 月)27.x.y28.x.y

后续计划

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

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

有关未来变更的更多信息,请参阅计划的重大变更页面。

生态系统 2023 回顾

·6 分钟阅读

回顾 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 月 1 日起,Apple 淘汰了用于 macOS 公证的旧版 altool,此版本将其从 Electron Forge 中完全移除。
  • 最低 Node.js 版本提高到 v16.4.0:此版本将最低所需 Node.js 版本设置为 16.4.0。
  • 停止支持 electron-prebuiltelectron-prebuilt-compileelectron-prebuilt 是 Electron 的 npm 模块的原始名称,但在 v1.3.1 中被 electron 取代。electron-prebuilt-compile 是该二进制文件的一个替代品,它具有增强的 DX 功能,但最终被废弃。

亮点

  • Google Cloud Storage 发布器作为我们更好地支持静态自动更新的一部分,Electron Forge 现在支持直接发布到 Google Cloud Storage!
  • ESM forge.config.js 支持Electron Forge 现在支持 ESM forge.config.js 文件。(附注:敬请期待 Electron 28 中的 ESM 入口点支持。)
  • Makers 现在并行运行在 Electron Forge 6 中,Makers 因 ✨ 历史遗留 ✨ 原因按顺序运行。此后,我们对 Make 步骤的并行化进行了测试,没有发现任何不良副作用,因此在为同一平台构建多个目标时,您应该会看到速度提升!
感谢!

🙇 非常感谢 mahnunchik 对 Forge 配置中 GCS 发布器和 ESM 支持的贡献!

更好的静态存储自动更新

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

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

更新服务器方法传统上是 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}`,
},
});
延伸阅读

📦 想了解更多?有关详细指南,请参阅 Forge 的自动更新文档

@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/packager 仓库设为私有,这导致了不幸的副作用,即抹去了我们的 GitHub 星星计数(在抹去之前超过 9000)。如果您是 Packager 的活跃用户,我们将不胜感激您点亮 ⭐ 星标 ⭐!

推出 @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 使用。

请尝试使用并向我们提供您的反馈意见,可以通过仓库的问题追踪器

后续计划?

我们将在下个月进入一年一度的十二月休整期。在此期间,我们将思考如何在 2024 年进一步改善 Electron 的开发体验。

有什么您希望我们接下来着手的工作吗?请告诉我们!

十二月休整月 (23 年 12 月)

·2 分钟阅读

Electron 项目将在 2023 年 12 月暂停,然后在 2024 年 1 月全面恢复。

通过 GIPHY


十二月保持不变

  1. 零日漏洞和其他主要安全相关的发布将按需发布。安全事件应通过 SECURITY.md 报告。
  2. 行为准则报告和审核将继续进行。

十二月将有所不同

  1. Electron 28.0.0 将于 12 月 5 日发布。在 Electron 28 之后,12 月份将不再有新的稳定版本发布。
  2. 12 月的最后两周没有 Nightly 和 Alpha 版本发布。
  3. 除了少数例外,没有拉取请求审查或合并。
  4. 任何仓库上都没有问题跟踪器更新。
  5. 维护者不会在 Discord 上提供调试帮助。
  6. 没有社交媒体内容更新。

展望未来

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

2024 年再见!