Skip to main content

谷歌2024年夏季编码计划

· 7 min read

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

🌐 We are excited to announce that Electron has been accepted as a mentoring organization for the 20th edition of Google Summer of Code (GSoC) 2024! Google Summer of Code is a global program focused on bringing new contributors into open source software development.

有关更多项目详情,请查看 Google 的 夏季编程宿营主页

🌐 For more program details, check out Google’s Summer of Code homepage.

关于我们

🌐 About us

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

🌐 Electron is a JavaScript framework for building cross-platform desktop applications using web technologies. The core Electron framework is a compiled binary executable built with Chromium and Node.js, and is mostly written in C++.

除了 Electron 核心之外,我们还开展各种项目以支持 Electron 组织,例如:

🌐 Outside of Electron core, we also work on a variety of projects to help sustain the Electron organization, such as:

作为一名夏季编程项目的贡献者,你将与 Electron 的一些核心贡献者合作,参与 github.com/electron 下的众多项目之一。

🌐 As a Summer of Code contributor, you would be collaborating with some of Electron’s core contributors on one of many projects under the github.com/electron umbrella.

应用前

🌐 Before applying

如果你对 Electron 不太熟悉,我们建议你先阅读文档,并在Electron Fiddle中尝试示例。

🌐 If you aren’t very familiar with Electron, we would recommend you start by reading the documentation and trying out examples in Electron Fiddle.

要了解更多关于 Electron 应用分发的信息,你还可以通过创建一个示例应用来尝试使用 Electron Forge

🌐 To learn more about Electron app distribution, you can also play around with Electron Forge by creating a sample application:

npm init electron-app@latest my-app

在稍微熟悉了代码之后,来加入 Electron Discord 服务器 上的讨论吧。

🌐 After familiarizing yourself with the code a bit, come join the conversation on the Electron Discord server.

info

如果这是你第一次参加 Google Summer of Code,或者你对开源项目还不太熟悉,我们建议在与社区互动之前,先阅读 Google 的贡献者指南作为第一步。

🌐 If this is your first time participating in Google Summer of Code or if you’re new to open source in general, we recommend reading Google’s Contributor Guide as a first step before engaging with the community.

起草你的提案

🌐 Drafting your proposal

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

🌐 Interested in collaborating with Electron? First, check out the seven project idea drafts that we have prepared. All of the listed ideas are currently open for proposals.

有其他想法希望我们考虑吗?我们也愿意接受不在提议项目列表上的新想法,但请确保你的方案有详细的说明和完整的规划。如有疑问,我们建议优先考虑我们列出的想法。

🌐 Have a different idea you’d like us to consider? We’re also open to accepting new ideas that are not on the proposed project list, but make sure your approach is thoroughly outlined and detailed. When in doubt, we recommend sticking with our listed ideas.

你的应用应包含:

🌐 Your application should include:

  • 你的提案:一份书面文件,详细描述你计划在整个夏季期间实现的目标。
  • 作为开发者的背景。如果你有简历,请附上一份。否则,请告诉我们你过去的技术经验。
    • 在某些字段缺乏经验并不会让你失去资格,但这将帮助我们的导师制定最佳计划来支持你,并确保你的暑期项目成功。

关于作为你 Electron 应用一部分需要提交的详细指南,请点击这里。 请直接在 Google 夏季编程(Google Summer of Code)门户提交提案。请注意,通过电子邮件发送给 Electron 团队的提案,而不是通过应用门户提交的,将不被视为最终提交。

如果你希望获得关于提案的更多指导,或者不确定应该包含哪些内容,我们还建议你参考此处的官方 Google 夏季编程大赛提案编写建议

🌐 If you want more guidance on your proposal or are unsure of what to include, we also recommend that you follow the official Google Summer of Code proposal writing advice here.

申请将于2024年3月18日开始,2024年4月2日截止。

🌐 Applications open on March 18th, 2024 and close on April 2nd, 2024.

info

我们2022年的谷歌夏季编程实习生@aryanshridhar表现非常出色!如果你想看看Aryan在夏天与Electron一起完成的工作,你可以在2022 GSoC项目档案中阅读他的报告。

🌐 Our 2022 Google Summer of Code intern, @aryanshridhar, did an amazing job! If you want to see what Aryan worked on during his summer with Electron, you can read his report in the 2022 GSoC program archives.

有问题吗?

🌐 Questions?

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

🌐 If you have questions we didn’t address in the blog post or inquiries for your proposal draft, please send us an email at summer-of-code@electronjs.org or check GSoC FAQ!

资源

🌐 Resources

Electron 29.0.0

· 7 min read

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

🌐 Electron 29.0.0 has been released! It includes upgrades to Chromium 122.0.6261.39, V8 12.2, and Node.js 20.9.0.


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

🌐 The Electron team is excited to announce the release of Electron 29.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release.

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

🌐 If you have any feedback, please share it with us on Twitter or Mastodon, or join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

显著变化

🌐 Notable Changes

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

技术栈变更

🌐 Stack Changes

Electron 29 将 Chromium 从 120.0.6099.56 升级到 122.0.6261.39,Node 从 18.18.2 升级到 20.9.0,V8 从 12.0 升级到 12.2

🌐 Electron 29 upgrades Chromium from 120.0.6099.56 to 122.0.6261.39, Node from 18.18.2 to 20.9.0, and V8 from 12.0 to 12.2.

新功能

🌐 New Features

  • 添加了新的 webUtils 模块,这是一个用于与 Web API 对象交互的实用层,用于替换 File.path 扩展。#38776
  • 已将 net 模块添加到 实用程序进程#40890
  • 添加了一个新的 Electron FusegrantFileProtocolExtraPrivileges,它使 file:// 协议采用更安全、更严格的行为,从而与 Chromium 保持一致。#40372
  • protocol.registerSchemesAsPrivileged 中添加了一个选项,以允许在自定义方案中使用 V8 代码缓存。#40544
  • app.{set|get}LoginItemSettings(settings) 迁移至在 macOS 13.0 及以上版本上使用苹果新推荐的底层框架。#37244

重大变化

🌐 Breaking Changes

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

🌐 Behavior Changed: ipcRenderer can no longer be sent over the contextBridge

尝试将整个 ipcRenderer 模块作为对象通过 contextBridge 发送,现在会导致桥接接收端收到一个空对象。此更改是为了消除/减轻安全风险。你不应直接在桥接中暴露 ipcRenderer 或其方法。相反,应提供如下的安全封装器:

🌐 Attempting to send the entire ipcRenderer module as an object over the contextBridge will now result in an empty object on the receiving side of the bridge. This change was made to remove / mitigate a security footgun. You should not directly expose ipcRenderer or its methods over the bridge. Instead, provide a safe wrapper like below:

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

已移除:app 上的 renderer-process-crashed 事件

🌐 Removed: renderer-process-crashed event on app

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

🌐 The renderer-process-crashed event on app has been removed. Use the new render-process-gone event instead.

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

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

已移除:WebContents<webview> 上的 crashed 事件

🌐 Removed: crashed event on WebContents and <webview>

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

🌐 The crashed events on WebContents and <webview> have been removed. Use the new render-process-gone event instead.

// 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 事件

🌐 Removed: gpu-process-crashed event on app

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

🌐 The gpu-process-crashed event on app has been removed. Use the new child-process-gone event instead.

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

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

26.x.y 支持终止

🌐 End of Support for 26.x.y

根据项目的支持政策,Electron 26.x.y 已达到支持结束。建议开发者和应用升级到更新版本的 Electron。

🌐 Electron 26.x.y has reached end-of-support as per the project's support policy. Developers and applications are encouraged to upgrade to a newer version of Electron.

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

下一步计划

🌐 What's Next

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

🌐 Did you know that Electron recently added a community Request for Comments (RFC) process? If you want to add a feature to the framework, RFCs can be a useful tool to start a dialogue with maintainers on its design. You can also see upcoming changes being discussed in the Pull Requests. To learn more, check out our Introducing electron/rfcs blog post, or check out the README of the electron/rfcs repository directly.

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

🌐 In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8.

你可以在这里找到 Electron 的公开时间线

🌐 You can find Electron's public timeline here.

有关未来更改的更多信息可以在计划中的重大变更页面上找到。

🌐 More information about future changes can be found on the Planned Breaking Changes page.

介绍 electron/rfcs

· 5 min read

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

🌐 Electron’s API Working Group is adopting an open Requests for Comments (RFC) process to help shepherd larger changes to Electron core.

为什么要发布 RFC?

🌐 Why RFCs?

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

🌐 In short, we want to smooth out the process of landing significant changes to Electron core.

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

🌐 Currently, new code changes are mostly discussed through issues and pull requests on GitHub. For most changes to Electron, this is a good system. Many bug fixes, documentation changes, and even new features are straightforward enough to review and merge asynchronously through standard GitHub flows.

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

🌐 For changes that are more significant—for instance, large API surfaces or breaking changes that would affect the majority of Electron apps—it makes sense for review to happen at the ideation stage before most of the code is written.

这个进程旨在向公众开放,这也将使广大开源社区更容易在这些潜在更改进入 Electron 之前提供反馈。

🌐 This process is designed to be open to the public, which will also make it easier for the open source community at large to give feedback on potential changes before they land in Electron.

它是如何工作的?

🌐 How does it work?

整个 RFC 进程都保存在 GitHub 上的 electron/rfcs 仓库中。具体步骤在该仓库的 README 中有详细说明。

🌐 The entire RFC process lives in the electron/rfcs repository on GitHub. The steps are described in detail in the repository README.

简而言之,当对 electron/rfcs 仓库提出 PR 时,RFC 会被标记为已提出。 已提出的 RFC 会变为:

🌐 In brief, an RFC is Proposed once a PR is made to the electron/rfcs repository. A Proposed RFC becomes:

  • 活跃 当 PR 被合并到仓库的 main 分支时,这意味着 Electron 维护者对在 electron/electron 中的实现是认可的,或者
  • 拒绝 如果该合并请求最终被驳回。
info

为了使 RFC 成为 活跃 状态,PR 必须得到至少 2 名 API 工作组成员的批准。在合并之前,RFC 应该同步展示,并获得至少三分之二工作组成员的法定人数一致通过。如果达成共识,将启动为期一个月的最终评论期,之后 PR 将被合并。

🌐 For the RFC to become Active, the PR must be approved by at least 2 API Working Group members. Before merging, the RFC should be presented synchronously and accepted unanimously by a quorum of at least two-thirds of the WG members. If consensus is reached, a one-month final comment period will be triggered, after which the PR will be merged.

如果实现已合并到 electron/electron,则活动 RFC 被视为完成

🌐 An Active RFC is Completed if the implementation has been merged into electron/electron.

谁可以参与?

🌐 Who can participate?

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

🌐 Anyone in the Electron community can submit RFCs or leave feedback on the electron/rfcs repository!

我们希望将这一进程变成双向对话,并鼓励社区参与,以便从未来可能使用这些 API 的 Electron 应用中获得多样化的意见。如果你有兴趣对当前提议的 RFC 提出反馈,Electron 维护者已经创建了一些供参考:

🌐 We wanted to make this process a two-way dialogue and encourage community participation to get a diverse set of opinions from Electron apps that might consume these APIs in the future. If you’re interested in leaving feedback on currently proposed RFCs, the Electron maintainers have already created a few:

致谢

🌐 Credits

Electron 的 RFC 进程是以许多成熟的开源 RFC 进程为模型的。许多想法和主要文案的灵感来源于:

🌐 Electron's RFC process was modeled on many established open source RFC processes. Inspiration for many ideas and major portions of copywriting go to:

关于 “runAsNode” CVE 的声明

· 7 min read

今天早些时候,Electron 团队注意到最近有几条针对若干知名 Electron 应用的公共 CVE 被提交。这些 CVE 与 Electron 的两个 保险丝 - runAsNodeenableNodeCliInspectArguments - 有关,并错误地声称如果这些组件未被主动禁用,远程攻击者能够通过它们执行任意代码。

🌐 Earlier today, the Electron team was alerted to several public CVEs recently filed against several notable Electron apps. The CVEs are related to two of Electron’s fuses - runAsNode and enableNodeCliInspectArguments - and incorrectly claim that a remote attacker is able to execute arbitrary code via these components if they have not been actively disabled.

我们不认为这些 CVE 是善意提交的。首先,该声明是不正确的——该配置并未启用远程代码执行。其次,尽管这些 CVE 中提到的公司都有漏洞赏金计划,但他们并未收到通知。最后,虽然我们确实认为禁用相关组件可以增强应用安全性,但我们不认为这些 CVE 的严重性等级正确。“严重”是用于最高危险的问题,而这里显然并非如此。

🌐 We do not believe that these CVEs were filed in good faith. First of all, the statement is incorrect - the configuration does not enable remote code execution. Secondly, companies called out in these CVEs have not been notified despite having bug bounty programs. Lastly, while we do believe that disabling the components in question enhances app security, we do not believe that the CVEs have been filed with the correct severity. “Critical” is reserved for issues of the highest danger, which is certainly not the case here.

任何人都可以申请 CVE。虽然这对整个软件行业的健康发展有益,但为了提升单个安全研究员的声誉而“获取 CVE”并没有帮助。

🌐 Anyone is able to request a CVE. While this is good for the overall health of the software industry, “farming CVEs” to bolster the reputation of a single security researcher is not helpful.

也就是说,我们理解,仅仅存在一个具有可怕 critical 严重性等级的 CVE 可能会导致终端用户困惑,因此作为一个项目,我们希望提供指导和帮助来处理这个问题。

🌐 That said, we understand that the mere existence of a CVE with the scary critical severity might lead to end user confusion, so as a project, we’d like to offer guidance and assistance in dealing with the issue.

这会对我有什么影响?

🌐 How might this impact me?

在审查了 CVE 后,Electron 团队认为这些 CVE 并不重要。

🌐 After reviewing the CVEs, the Electron team believes that these CVEs are not critical.

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

🌐 An attacker needs to already be able to execute arbitrary commands on the machine, either by having physical access to the hardware or by having achieved full remote code execution. This bears repeating: The vulnerability described requires an attacker to already have access to the attacked system.

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

🌐 Chrome, for example, does not consider physically-local attacks in their threat model:

我们认为这些攻击不在 Chrome 的威胁模型范围内,因为对于已经以你的身份登录设备的恶意用户,或能够以操作系统用户账户的权限运行软件的攻击者,Chrome(或任何应用)都无法防御。这样的攻击者可以修改可执行文件和 DLL,改变环境变量如 PATH,修改配置文件,读取你用户账户拥有的任何数据,发送到自己的邮箱,等等。这样的攻击者对你的设备拥有完全控制权,而 Chrome 无论做什么都无法提供有效的防御保证。这个问题并不是 Chrome 特有的——所有应用都必须信任物理本地用户。

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

🌐 The exploit described in the CVEs allows an attacker to then use the impacted app as a generic Node.js process with inherited TCC permissions. So if the app, for example, has been granted access to the address book, the attacker can run the app as Node.js and execute arbitrary code which will inherit that address book access. This is commonly known as a “living off the land” attack. Attackers usually use PowerShell, Bash, or similar tools to run arbitrary code.

我会受到影响吗?

🌐 Am I impacted?

默认情况下,Electron 的所有已发布版本都启用了 runAsNodeenableNodeCliInspectArguments 功能。如果你没有按照 Electron Fuses 文档 中的说明将它们关闭,你的应用同样有可能被用于“利用现有系统资源进行攻击”。再次强调,攻击者需要 已经 能够在受害者的计算机上执行代码和程序。

🌐 By default, all released versions of Electron have the runAsNode and enableNodeCliInspectArguments features enabled. If you have not turned them off as described in the Electron Fuses documentation, your app is equally vulnerable to being used as a “living off the land” attack. Again, we need to stress that an attacker needs to already be able to execute code and programs on the victim’s machine.

缓解措施

🌐 Mitigation

解决此问题最简单的方法是在你的 Electron 应用中禁用 runAsNode 熔断器。runAsNode 熔断器用于切换是否启用 ELECTRON_RUN_AS_NODE 环境变量。有关如何切换这些熔断器的信息,请参阅 Electron 熔断器文档

🌐 The easiest way to mitigate this issue is to disable the runAsNode fuse within your Electron app. The runAsNode fuse toggles whether the ELECTRON_RUN_AS_NODE environment variable is respected or not. Please see the Electron Fuses documentation for information on how to toggle theses fuses.

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

🌐 Please note that if this fuse is disabled, then process.fork in the main process will not function as expected as it depends on this environment variable to function. Instead, we recommend that you use Utility Processes, which work for many use cases where you need a standalone Node.js process (like a Sqlite server process or similar scenarios).

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

🌐 You can find more info about security best practices we recommend for Electron apps in our Security Checklist.

Electron 28.0.0

· 6 min read

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

🌐 Electron 28.0.0 has been released! It includes upgrades to Chromium 120.0.6099.56, V8 12.0, and Node.js 18.18.2.


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

🌐 The Electron team is excited to announce the release of Electron 28.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release.

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

🌐 If you have any feedback, please share it with us on Twitter or Mastodon, or join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

显著变化

🌐 Notable Changes

  • 已实现对 ECMAScript 模块(或 ESM)的支持(什么是 ECMAScript 模块?在这里了解更多)。这包括对 Electron 本身的 ESM 支持,以及诸如 UtilityProcess API 入口点等字段的支持。有关详细信息,请参阅我们的 ESM 文档
  • 除了在 Electron 本身启用 ESM 支持之外,Electron Forge 也支持使用 ESM 来打包、构建和开发 Electron 应用。你可以在 Forge v7.0.0 或更高版本中找到此支持。

技术栈变更

🌐 Stack Changes

新功能

🌐 New Features

  • 已启用 ESM 支持。 #37535
  • 已为 UtilityProcess API 添加 ESM 入口点。#40047
  • display 对象添加了几个属性,包括 detectedmaximumCursorSizenativeOrigin#40554
  • 在 Linux 上添加了对 ELECTRON_OZONE_PLATFORM_HINT 环境变量的支持。 #39792

重大变化

🌐 Breaking Changes

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

🌐 Behavior Changed: WebContents.backgroundThrottling set to false affects all WebContents in the host BrowserWindow

WebContents.backgroundThrottling 设置为 false 将禁用 BrowserWindow 中所有由其显示的 WebContents 的帧率限制。

已移除:BrowserWindow.setTrafficLightPosition(position)

🌐 Removed: 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()

🌐 Removed: 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()

🌐 Removed: ipcRenderer.sendTo()

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

🌐 The ipcRenderer.sendTo() API has been removed. It should be replaced by setting up a MessageChannel between the renderers.

IpcRendererEventsenderIdsenderIsMainFrame 属性也已被移除。

🌐 The senderId and senderIsMainFrame properties of IpcRendererEvent have been removed as well.

已移除:app.runningUnderRosettaTranslation

🌐 Removed: app.runningUnderRosettaTranslation

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

🌐 The app.runningUnderRosettaTranslation property has been removed. Use app.runningUnderARM64Translation instead.

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

25.x.y 支持终止

🌐 End of Support for 25.x.y

根据项目的支持政策,Electron 25.x.y 已达到支持终止。建议开发者和应用升级到更新的 Electron 版本。

🌐 Electron 25.x.y has reached end-of-support as per the project's support policy. Developers and applications are encouraged to upgrade to a newer version of Electron.

E28(2023年12月)E29(2024年2月)E30(2024年4月)
28.x.y29.x.y30.x.y
27.x.y28.x.y29.x.y
26.x.y27.x.y28.x.y

下一步计划

🌐 What's Next

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

🌐 In the short term, you can expect the team to continue to focus on keeping up with the development of the major components that make up Electron, including Chromium, Node, and V8.

你可以在这里找到 Electron 的公开时间线

🌐 You can find Electron's public timeline here.

有关未来更改的更多信息可以在计划中的重大变更页面上找到。

🌐 More information about future changes can be found on the Planned Breaking Changes page.

生态系统 2023 年回顾

· 9 min read

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

🌐 Reflecting on the improvements and changes in Electron's developer ecosystem in 2023.


在过去的几个月里,我们一直在 Electron 生态系统中进行一些改进,以全面提升 Electron 应用的开发者体验!这里是来自 Electron 总部的最新更新的快速概览。

🌐 In the past few months, we've been cooking up some changes across the Electron ecosystem to supercharge the developer experience for Electron apps! Here’s a swift rundown of the latest additions straight from Electron HQ.

Electron Forge 7 及更高版本

🌐 Electron Forge 7 and beyond

Electron Forge 7 - 我们用于打包和分发 Electron 应用的一体化工具的最新主要版本 - 现已推出。

🌐 Electron Forge 7 — the newest major version of our all-in-one tool for packaging and distributing Electron applications — is now available.

虽然 Forge 6 是对 v5 的完全重写,v7 的范围较小,但仍然包含一些破坏性更改。今后,我们将继续发布 Forge 的主要版本,以便在需要进行破坏性更改时使用。

🌐 While Forge 6 was a complete rewrite from v5, v7 is smaller in scope but still contains a few breaking changes. Going forward, we will continue to publish major versions of Forge as breaking changes need to be made.

欲了解更多详情,请参见 GitHub 上完整的 Forge v7.0.0 更新日志

🌐 For more details, see the full Forge v7.0.0 changelog on GitHub.

重大变更

🌐 Breaking changes

  • 切换到 macOS 公证的 notarytool 自 2023-11-01 起,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 是该二进制文件的一个替代方案,提供了增强的开发者体验功能,但最终被放弃。

亮点

🌐 Highlights

  • Google 云存储发布者 作为我们推动更好支持静态自动更新的一部分,Electron Forge 现在支持直接发布到 Google 云存储!
  • ESM forge.config.js 支持 Electron Forge 现在支持 ESM forge.config.js 文件。(附注:期待在 Electron 28 中支持 ESM 入口点。)
  • 现在 Makers 可以并行运行 在 Electron Forge 6 中,Makers 出于✨传统✨原因是顺序运行的。从那时起,我们已经在 Make 步骤中测试了并行化,没有出现任何负面影响,因此在为同一平台构建多个目标时,你应该会看到速度提升!
谢谢!

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

更完善的静态存储自动更新

🌐 Better static storage auto updates

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

🌐 Squirrel.Windows and Squirrel.Mac are platform-specific updater technologies that back Electron’s built-in autoUpdater module. Both projects support auto updates via two methods:

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

更新服务器方法传统上一直是 Electron 应用的推荐方法(并且提供了对更新逻辑的额外自定义),但它有一个很大的缺点 - 如果应用是闭源的,它需要维护自己的服务器实例。

🌐 The update server method has traditionally been the recommended approach for Electron apps (and provides additional customization of update logic), but it has a major downside—it requires apps to maintain their own server instance if they are closed-source.

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

🌐 On the other hand, the static storage method has always been possible, but was undocumented within Electron and poorly supported across Electron tooling packages.

@MarshallOfSound 的出色工作下,无服务器自动应用更新的更新进程被大大简化了:

🌐 With some great work from @MarshallOfSound, the update story for serverless automatic app updates has been drastically streamlined:

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

一旦你的 Makers 和 Publishers 配置为将更新清单上传到云文件存储,你只需几行配置即可启用自动更新:

🌐 Once your Makers and Publishers are configured to upload update manifests to cloud file storage, you can enable auto updates with only a few lines of configuration:

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

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

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

@electron/ 扩展宇宙

🌐 The @electron/ extended universe

当 Electron 刚刚起步时,社区发布了许多用于增强开发、打包和分发 Electron 应用体验的包。随着时间的推移,其中许多包被纳入 Electron 的 GitHub 组织,由核心团队承担维护工作。

🌐 When Electron first started, the community published many packages to enhance the experience of developing, packaging, and distributing Electron apps. Over time, many of these packages were incorporated into Electron’s GitHub organization, with the core team taking on the maintenance burden.

在2022年,我们开始将所有这些一方工具统一到 npm 上的 @electron/ 命名空间下。这个变化意味着,以前是 electron-foo 的包现在在 npm 上变为 @electron/foo,而以前命名为 electron/electron-foo 的仓库现在在 GitHub 上变为 electron/foo。这些变化有助于清晰地区分一方项目和用户项目。这包括许多常用的包,例如:

🌐 In 2022, we began unifying all these first-party tools under the @electron/ namespace on npm. This change means that packages that used to be electron-foo are now @electron/foo on npm, and repositories that used to be named electron/electron-foo are now electron/foo on GitHub. These changes help clearly delineate first-party projects from userland projects. This includes many commonly used packages, such as:

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

今后,我们发布的所有第一方软件包也将位于 @electron/ 命名空间中。对此规则有两个例外:

🌐 Going forward, all first-party packages we release will also be in the @electron/ namespace. There are two exceptions to this rule:

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

⭐ 在此进程中,我们还不小心将 electron/packager 仓库设为私有,这带来了一个不幸的副作用——清除了我们在 GitHub 上的星标数量(清除前超过 9000 个)。如果你是 Packager 的活跃用户,我们将非常感激你的 ⭐ Star ⭐!

介绍 @electron/windows-sign

🌐 Introducing @electron/windows-sign

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

🌐 Starting on 2023-06-01, industry standards began requiring keys for Windows code signing certificates to be stored on FIPS-compliant hardware.

实际上,这意味着在持续集成 (CI) 环境中构建和签名的应用的代码签名变得更加困难,因为许多 Electron 工具会将证书文件和密码作为配置参数,并尝试使用硬编码逻辑从那里进行签名。

🌐 In practice, this meant that code signing became a lot harder for apps that build and sign in CI environments, since many Electron tools take in a certificate file and password as config parameters and attempt to sign from there using hardcoded logic.

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

🌐 This situation has been a common pain point for Electron developers, which is why we have been working on a better solution that isolates Windows code signing into its own standalone step, similar to what @electron/osx-sign does on macOS.

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

🌐 In the future, we plan on fully integrating this package into the Electron Forge toolchain, but it currently lives on its own. The package is currently available for installation at npm install --save-dev @electron/windows-sign and can used programmatically or via CLI.

请试用一下,并在仓库的问题跟踪中给我们反馈!

🌐 Please try it out and give us your feedback in the repo’s issue tracker!

下一步是什么?

🌐 What's next?

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

🌐 We'll be entering our annual December quiet period next month. While we do, we'll be thinking about how we can make the Electron development experience even better in 2024.

你希望我们接下来做些什么吗?请告诉我们!

🌐 Is there anything you'd like to see us work on next? Let us know!

十二月的宁静月份(2023年12月)

· 2 min read

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

🌐 The Electron project will pause for the month of December 2023, then return to full speed in January 2024.

via GIPHY


12 月会有什么相同之处?

🌐 What will be the same in December

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

12 月会有什么不同?

🌐 What will be different in December

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

展望未来

🌐 Going forward

这是我们第三年进行静默期实验,到目前为止,我们在平衡一个月剩余与随后保持正常发布节奏方面已经取得了很大成功。因此,我们决定将其作为今后发布日历的常规部分。我们仍将在每个日历年的最后一个稳定版本中放入提醒。

🌐 This is our third year running our quiet period experiment, and we've had a lot of success so far in balancing a month of rest with maintaining our normal release cadence afterwards. Therefore, we've decided to make this a regular part of our release calendar going forward. We'll still be putting a reminder into the last stable release of every calendar year.

2024 年再见!

🌐 See you all in 2024!

Electron 27.0.0

· 7 min read

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

🌐 Electron 27.0.0 has been released! It includes upgrades to Chromium 118.0.5993.32, V8 11.8, and Node.js 18.17.1.


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

🌐 The Electron team is excited to announce the release of Electron 27.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release.

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

🌐 If you have any feedback, please share it with us on Twitter or Mastodon, or join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

从漏洞到防护:通过沙箱强化应用

· 8 min read

自从CVE-2023-4863:WebP中的堆缓冲区溢出被公开以来,已经过去一周多,这导致了一系列新的软件发布,用于渲染 webp 图片:macOS、iOS、Chrome、Firefox 以及各种 Linux 发行版都收到了更新。这是在公民实验室的调查之后发现的,他们发现一个由“位于华盛顿特区的民间社会组织”使用的 iPhone 正在通过 iMessage 中的零点击漏洞遭受攻击。

🌐 It’s been more than a week since CVE-2023-4863: Heap buffer overflow in WebP was made public, leading to a flurry of new releases of software rendering webp images: macOS, iOS, Chrome, Firefox, and various Linux distributions all received updates. This followed investigations by Citizen Lab, discovering that an iPhone used by a “Washington DC-based civil society organization” was under attack using a zero-click exploit within iMessage.

Electron 也迅速行动起来,并在同一天发布了新版本:如果你的应用呈现任何用户提供的内容,你应该更新你的 Electron 版本——v27.0.0-beta.2、v26.2.1、v25.8.1、v24.8.3 和 v22.3.24 都包含修复后的 libwebp,该库负责渲染 webp 图片。

🌐 Electron, too, spun into action and released new versions the same day: If your app renders any user-provided content, you should update your version of Electron - v27.0.0-beta.2, v26.2.1, v25.8.1, v24.8.3, and v22.3.24 all contain a fixed version of libwebp, the library responsible for rendering webp images.

现在我们都清楚地意识到,像“渲染图片”这样简单的交互也可能存在危险,我们想借此机会提醒大家,Electron 内置了一个进程沙盒,它可以限制下一次大规模攻击的波及范围 - 无论它是什么。

🌐 Now that we are all freshly aware that an interaction as innocent as “rendering an image” is a potentially dangerous activity, we want to use this opportunity to remind everyone that Electron comes with a process sandbox that will limit the blast radius of the next big attack — whatever it may be.

自从 Electron v1 开始,沙箱功能就已经可用,并且在 v20 中默认启用,但我们知道许多应用(尤其是那些存在已久的应用)可能在它们的代码中某处有一个 sandbox: false —— 或者一个 nodeIntegration: true,当没有明确的 sandbox 设置时,也会同样禁用沙箱。这是可以理解的:如果你和我们一起走过了很长时间,你可能享受过将 require("child_process")require("fs") 扔进运行 HTML/CSS 的同一代码中的强大功能。

🌐 The sandbox was available ever since Electron v1 and enabled by default in v20, but we know that many apps (especially those that have been around for a while) may have a sandbox: false somewhere in their code – or a nodeIntegration: true, which equally disables the sandbox when there is no explicit sandbox setting. That’s understandable: If you’ve been with us for a long time, you probably enjoyed the power of throwing a require("child_process") or require("fs") into the same code that runs your HTML/CSS.

在我们讨论你如何迁移到沙盒之前,先让我们讨论一下你为什么想要这样做。

🌐 Before we talk about how you migrate to the sandbox, let’s first discuss why you want it.

沙箱在所有渲染进程周围设置了一个严格的隔离环境,确保无论内部发生什么,代码都在受限的环境中执行。作为一个概念,它比 Chromium 要早得多,并且作为功能由所有主要操作系统提供。Electron 和 Chromium 的沙箱构建在这些系统功能之上。即使你从未显示用户生成的内容,也应考虑渲染器可能被攻破的可能性:从复杂的供应链攻击到简单的小漏洞,都可能导致渲染器执行你未完全预期的操作。

🌐 The sandbox puts a hard cage around all renderer processes, ensuring that no matter what happens inside, code is executed inside a restricted environment. As a concept, it's a lot older than Chromium, and provided as a feature by all major operating systems. Electron's and Chromium's sandbox build on top of these system features. Even if you never display user-generated content, you should consider the possibility that your renderer might get compromised: Scenarios as sophisticated as supply chain attacks and as simple as little bugs can lead to your renderer doing things you didn't fully intend for it to do.

沙盒使这种情况的威胁大大降低:内部的进程可以自由使用 CPU 周期和内存——仅此而已。进程不能写入磁盘或显示自己的窗口。在我们提到的 libwep 漏洞案例中,沙盒确保攻击者无法安装或运行恶意软件。实际上,在最初针对员工 iPhone 的 Pegasus 攻击中,攻击者专门针对一个非沙盒化的图片处理进程,以获取手机访问权限,首先突破了通常沙盒化的 iMessage 的边界。当像本例中的 CVE 漏洞被公布时,你仍然需要将 Electron 应用升级到安全版本——但与此同时,攻击者能造成的损害量会大幅度受限。

🌐 The sandbox makes that scenario a lot less scary: A process inside gets to freely use CPU cycles and memory — that’s it. Processes cannot write to disk or display their own windows. In the case of our libwep bug, the sandbox makes sure that an attacker cannot install or run malware. In fact, in the case of the original Pegasus attack on the employee’s iPhone, the attack specifically targeted a non-sandboxed image process to gain access to the phone, first breaking out of the boundaries of the normally sandboxed iMessage. When a CVE like the one in this example is announced, you still have to upgrade your Electron apps to a secure version — but in the meantime, the amount of damage an attacker can do is limited dramatically.

将一个原生 Electron 应用从 sandbox: false 迁移到 sandbox: true 是一项大工程。我知道,因为即使我个人撰写了 Electron 安全指南 的初稿,我也未能将自己的应用迁移到使用它。这个周末情况有所改变,我也建议你进行相应的更改。

🌐 Migrating a vanilla Electron application from sandbox: false to sandbox: true is an undertaking. I know, because even though I have personally written the first draft of the Electron Security Guidelines, I have not managed to migrate one of my own apps to use it. That changed this weekend, and I recommend that you change it, too.

Don’t be scared by the number of line changes, most of it is in package-lock.json

你需要解决两件事:

🌐 There are two things you need to tackle:

  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 的强大功能,因为我决定利用这个机会以许多其他方式重构我的代码。

🌐 All in all, the entire process took me around four days — and that includes a lot of scratching my head at how to wrangle Webpack’s massive power, since I decided to use the opportunity to refactor my code in plenty of other ways, too.

Electron 26.0.0

· 4 min read

Electron 26.0.0 已经发布!它包括对 Chromium 116.0.5845.62、V8 11.2 和 Node.js 18.16.1 的升级。请往下阅读了解更多详情!

🌐 Electron 26.0.0 has been released! It includes upgrades to Chromium 116.0.5845.62, V8 11.2, and Node.js 18.16.1. Read below for more details!


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

🌐 The Electron team is excited to announce the release of Electron 26.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release.

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

🌐 If you have any feedback, please share it with us on Twitter, or join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.