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 安装它，或者从我们的发布网站下载它。继续阅读以了解有关此版本的详细信息。

如果您有任何反馈，请在 Twitter 或 Mastodon 上与我们分享，或加入我们的社区 Discord！错误和功能请求可以在 Electron 的 issue tracker 中报告。

值得注意的更改​

亮点​

• Windows 上现在支持 ASAR 完整性熔断器 (#40504)
  • 如果配置不正确，启用 ASAR 完整性的现有应用程序可能无法在 Windows 上运行。使用 Electron 打包工具的应用程序应升级到 @electron/packager@18.3.1 或 @electron/forge@7.4.0。
  • 请查看我们的 ASAR 完整性教程 以获取更多信息。
• 添加了 WebContentsView 和 BaseWindow 主进程模块，弃用并替换了 BrowserView (#35658)。在 这篇博客文章 中了解更多关于如何从 BrowserView 迁移到 WebContentsView 的信息。
  • BrowserView 现在是 WebContentsView 的 shim，并且旧的实现已被删除。
  • 请参阅 我们的 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)
• 为从实用程序进程使用 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 填充整个窗口，这两种方法的行为是相同的。但是，在更高级的用例中，BrowserView 在 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 已被接受为 2024 年 Google 编程之夏 (GSoC) 第 20 版的指导组织！Google 编程之夏是一项全球性计划，专注于将新的贡献者引入开源软件开发。

有关更多计划详细信息，请查看 Google 的 编程之夏主页。

关于我们​

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

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

• 最终用户分发工具（例如 Electron Forge 和 update.electronjs.org）。
• Electron 开发人员的学习资料（例如 electronjs.org 和 Electron Fiddle）。
• 简化开发人员生产力的内部工具（例如 Electron 构建工具 和 Sheriff）。

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

申请前​

如果您不太熟悉 Electron，我们建议您首先阅读 文档 并尝试 Electron Fiddle 中的示例。

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

npm init electron-app@latest my-app

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

起草您的提案​

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

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

您的申请应包括

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

此处提供了关于作为 Electron 应用程序一部分提交内容的详细指南。 将提案直接提交到 Google 编程之夏门户。请注意，通过电子邮件发送给 Electron 团队而不是通过申请门户提交的提案将不被视为最终提交。

如果您想获得有关提案的更多指导或不确定要包含哪些内容，我们还建议您遵循 此处的官方 Google 编程之夏提案撰写建议。

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

有问题吗？​

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

资源​

• Electron Google 编程之夏 2024 构想列表
• Electron Google 编程之夏 2024 贡献者指南
• Google 编程之夏学生/贡献者指南

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 安装它，或者从我们的 发布网站 下载它。继续阅读以了解有关此版本的详细信息。

如果您有任何反馈，请在 Twitter 或 Mastodon 上与我们分享，或加入我们的社区 Discord！错误和功能请求可以在 Electron 的 issue tracker 中报告。

值得注意的更改​

亮点​

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

下一步是什么​

您是否知道 Electron 最近添加了社区征求意见 (RFC) 流程？如果您想向框架添加功能，RFC 可以成为与维护人员就其设计展开对话的有用工具。您还可以在拉取请求中查看正在讨论的即将到来的更改。要了解更多信息，请查看我们的 Introducing electron/rfcs 博客文章，或直接查看 electron/rfcs 存储库的 README。

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

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

有关未来更改的更多信息，请访问计划的重大更改页面。

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

为什么选择 RFC？​

简而言之，我们希望简化 Electron 核心重大更改的流程。

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

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

此过程旨在向公众开放，这也将使更广泛的开源社区更容易在潜在更改登陆 Electron 之前提供反馈。

它是如何工作的？​

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

简而言之，一旦向 electron/rfcs 存储库发出 PR，RFC 就会被提议。提议的 RFC 变为

• 活动，当 PR 合并到存储库的 main 分支中时，这意味着 Electron 维护人员同意在 electron/electron 中实现，或者
• 如果 PR 最终被拒绝，则为拒绝。

如果实现已合并到 electron/electron 中，则活动 RFC 将完成。

谁可以参与？​

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

• 要查看活动 RFC 的列表，请参阅 存储库中的 text 文件夹。
• 要对提议的 RFC 留下反馈，请查看 打开的 PR 列表。
• 要提交新的 RFC，请查看存储库的 README 和 RFC 模板。

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

• Electron C API
• Service Workers 的预加载领域

鸣谢​

Electron 的 RFC 流程以许多已建立的开源 RFC 流程为模型。许多想法和大部分文案的灵感来自

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

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

我们不认为这些 CVE 是出于善意提交的。首先，该声明不正确 - 该配置不启用远程代码执行。其次，这些 CVE 中点名的公司尚未收到通知，尽管他们有漏洞赏金计划。最后，虽然我们确实认为禁用有问题的组件可以增强应用程序安全性，但我们不认为这些 CVE 是以正确的严重性提交的。“严重”是为最高危险的问题保留的，而这里的情况肯定不是这样。

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

也就是说，我们理解仅仅存在一个严重性为“严重”的 CVE 可能会导致最终用户感到困惑，因此作为一个项目，我们希望提供指导和帮助来解决此问题。

这可能对我有什么影响？​

在审查 CVE 后，Electron 团队认为这些 CVE 并不严重。

攻击者需要已经能够在机器上执行任意命令，这可以通过物理访问硬件或已实现完全远程代码执行来实现。这一点需要重复强调：所描述的漏洞要求攻击者已经能够访问被攻击的系统。

例如，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 环境变量。有关如何切换这些 fuse 的信息，请参阅 Electron Fuses 文档。

请注意，如果禁用此 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 使用 npm install electron@latest 安装它，或从我们的发布网站下载它。继续阅读以了解有关此版本的详细信息。

如果您有任何反馈，请在 Twitter 或 Mastodon 上与我们分享，或加入我们的社区 Discord！错误和功能请求可以在 Electron 的 issue tracker 中报告。

值得注意的更改​

亮点​

• 实现了对 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

重大更改​

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

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

已移除：BrowserWindow.setTrafficLightPosition(position)​

BrowserWindow.setTrafficLightPosition(position) 已被移除，应使用 BrowserWindow.setWindowButtonPosition(position) 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 代替，当没有自定义位置时，后者返回 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 发布者： 作为我们更好地支持静态自动更新的一部分，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 makers 现在可以配置为输出与 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 将继续在其 @electron-forge/ 命名空间下发布其所有 monorepo 软件包。

介绍 @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 使用。

请试用它，并在 存储库的问题跟踪器中向我们提供您的反馈！

下一步是什么？​

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

您希望我们接下来致力于哪些方面？请告诉我们！

Electron 项目将于 2023 年 12 月暂停一个月，然后在 2024 年 1 月恢复全速运转。

via GIPHY

12 月份将保持不变的内容​

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

12 月份将有所不同的内容​

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

展望未来​

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

2024 年再见！

Electron 27.0.0 已发布！它包括 Chromium 118.0.5993.32、V8 11.8 和 Node.js 18.17.1 的升级。

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

如果您有任何反馈，请在 Twitter 或 Mastodon 上与我们分享，或加入我们的社区 Discord！错误和功能请求可以在 Electron 的 issue tracker 中报告。

值得注意的更改​

堆栈更改​

• Chromium 118.0.5993.32
  • Chrome 118 中的新功能
  • DevTools 118 中的新功能
• Node.js 18.17.1
  • Node 18.17.1 博客文章
  • Node 18.17.0 博客文章
• V8 11.8

重大更改​

已移除：macOS 10.13 / 10.14 支持​

macOS 10.13 (High Sierra) 和 macOS 10.14 (Mojave) 不再受 Chromium 支持。

旧版本的 Electron 将继续在这些操作系统上运行，但运行 Electron v27.0.0 及更高版本需要 macOS 10.15 (Catalina) 或更高版本。

已弃用：ipcRenderer.sendTo()​

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

IpcRendererEvent 的 senderId 和 senderIsMainFrame 属性也已被弃用。

已移除：systemPreferences 中的颜色方案事件​

以下 systemPreferences 事件已被移除

• inverted-color-scheme-changed
• high-contrast-color-scheme-changed

请改用 nativeTheme 模块上的新 updated 事件。

// Removed
systemPreferences.on('inverted-color-scheme-changed', () => {
  /* ... */
});
systemPreferences.on('high-contrast-color-scheme-changed', () => {
  /* ... */
});

// Replace with
nativeTheme.on('updated', () => {
  /* ... */
});

已移除：webContents.getPrinters​

webContents.getPrinters 方法已被移除。请改用 webContents.getPrintersAsync。

const w = new BrowserWindow({ show: false });

// Removed
console.log(w.webContents.getPrinters());
// Replace with
w.webContents.getPrintersAsync().then((printers) => {
  console.log(printers);
});

已移除：systemPreferences.{get,set}AppLevelAppearance 和 systemPreferences.appLevelAppearance​

systemPreferences.getAppLevelAppearance 和 systemPreferences.setAppLevelAppearance 方法以及 systemPreferences.appLevelAppearance 属性已被移除。请改用 nativeTheme 模块。

// Removed
systemPreferences.getAppLevelAppearance();
// Replace with
nativeTheme.shouldUseDarkColors;

// Removed
systemPreferences.appLevelAppearance;
// Replace with
nativeTheme.shouldUseDarkColors;

// Removed
systemPreferences.setAppLevelAppearance('dark');
// Replace with
nativeTheme.themeSource = 'dark';

已移除：systemPreferences.getColor 的 alternate-selected-control-text 值​

systemPreferences.getColor 的 alternate-selected-control-text 值已被移除。请改用 selected-content-background。

// Removed
systemPreferences.getColor('alternate-selected-control-text');
// Replace with
systemPreferences.getColor('selected-content-background');

新功能​

• 添加了应用程序辅助功能透明度设置 API #39631
• 增加了对 chrome.scripting 扩展 API 的支持 #39675
• 默认启用 WaylandWindowDecorations #39644

对 24.x.y 的支持已结束​

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

对 22.x.y 的扩展支持已结束​

今年早些时候，Electron 团队将 Electron 22 计划的生命周期结束日期从 2023 年 5 月 30 日延长至 2023 年 10 月 10 日，以匹配 Chrome 对 Windows 7/8/8.1 的扩展支持（请参阅 告别 Windows 7/8/8.1 了解更多详细信息）。

根据项目的 支持策略和此支持扩展，Electron 22.x.y 已达到支持终止日期。这将把支持版本降回最新的三个稳定主要版本，并将结束对 Windows 7/8/8.1 的官方支持。

下一步是什么​

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

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

有关未来更改的更多信息，请访问计划的重大更改页面。

自从 CVE-2023-4863：WebP 中的堆缓冲区溢出漏洞 公开以来已经过去一周多了，这导致了大量新的软件渲染 webp 图像的发布：macOS、iOS、Chrome、Firefox 和各种 Linux 发行版都收到了更新。此前，公民实验室进行调查，发现华盛顿特区一家民间组织使用的 iPhone 正在遭受 iMessage 中的零点击漏洞攻击。

Electron 也迅速采取行动，并在同一天发布了新版本：如果您的应用程序渲染任何用户提供的内容，您应该更新您的 Electron 版本 - v27.0.0-beta.2、v26.2.1、v25.8.1、v24.8.3 和 v22.3.24 都包含修复后的 libwebp 版本，该库负责渲染 webp 图像。

现在我们都新鲜地意识到，像“渲染图像”这样无辜的交互也可能是一种危险的活动，我们想借此机会提醒大家，Electron 自带进程沙箱，这将限制下一次重大攻击（无论它是什么）的爆炸半径。

沙箱自 Electron v1 起就已可用，并在 v20 中默认启用，但我们知道许多应用程序（尤其是那些存在已久的应用程序）的代码中某处可能存在 sandbox: false - 或 nodeIntegration: true，当没有显式 sandbox 设置时，它同样会禁用沙箱。这是可以理解的：如果您与我们同行已久，您可能享受过在运行 HTML/CSS 的同一代码中抛出 require("child_process") 或 require("fs") 的强大功能。

在我们讨论如何迁移到沙箱之前，让我们首先讨论为什么您需要它。

沙箱在所有渲染器进程周围设置了一个硬笼子，确保无论内部发生什么，代码都在受限环境中执行。作为一个概念，它比 Chromium 早得多，并且由所有主要操作系统作为一项功能提供。Electron 和 Chromium 的沙箱构建在这些系统功能之上。即使您从不显示用户生成的内容，您也应考虑您的渲染器可能受到攻击的可能性：供应链攻击等复杂的场景以及小错误等简单的场景都可能导致您的渲染器执行您不完全希望它执行的操作。

沙箱使这种情况变得不那么可怕：内部进程可以自由使用 CPU 周期和内存 —— 仅此而已。进程无法写入磁盘或显示自己的窗口。在我们的 libwep 错误的情况下，沙箱确保攻击者无法安装或运行恶意软件。事实上，在最初的 Pegasus 攻击员工 iPhone 的案例中，该攻击专门针对非沙箱图像进程以获取对手机的访问权限，首先突破了通常沙箱化的 iMessage 的边界。当宣布像本例中的 CVE 时，您仍然必须将您的 Electron 应用程序升级到安全版本 —— 但与此同时，攻击者可以造成的损害量会大大减少。

将 vanilla Electron 应用程序从 sandbox: false 迁移到 sandbox: true 是一项艰巨的任务。我知道，因为即使我亲自撰写了 Electron 安全指南 的初稿，我也没有设法将我自己的一个应用程序迁移到使用它。这个周末情况发生了变化，我建议您也做出改变。

您需要解决两件事

1. 如果您在 preload 脚本或实际的 WebContents 中使用 Node.js 代码，您需要将所有 Node.js 交互移动到主进程（或者，如果您喜欢，可以使用实用程序进程）。鉴于渲染器变得多么强大，您的绝大多数代码很可能不需要重构。

   请查阅我们关于 进程间通信 的文档。在我的例子中，我移动了很多代码并将其包装在 ipcRenderer.invoke() 和 ipcMain.handle() 中，但该过程很简单且很快完成。在这里稍微注意一下您的 API - 如果您构建一个名为 executeCodeAsRoot(code) 的 API，沙箱将不会为您的用户提供太多保护。

2. 由于启用沙箱会禁用预加载脚本中的 Node.js 集成，因此您不能再使用 require("../my-script")。换句话说，您的预加载脚本需要是单个文件。

   有多种方法可以做到这一点：Webpack、esbuild、parcel 和 rollup 都可以完成这项工作。我使用了 Electron Forge 出色的 Webpack 插件，同样流行的 electron-builder 的用户可以使用 electron-webpack。

总而言之，整个过程大约花了我四天时间——这包括很多挠头思考如何驾驭 Webpack 的强大功能，因为我决定借此机会以其他多种方式重构我的代码。