在蒙特利尔的 Node+JS Interactive 活动上，OpenJS 基金会宣布已接受 Electron 加入该基金会的孵化项目。该基金会致力于通过提供一个中立的组织来托管和维护项目，以及为整个社区的利益共同资助活动，从而支持 JavaScript 生态系统和 Web 技术的健康发展。

OpenJS 基金会托管了许多开源 JavaScript 项目，包括 jQuery、Node.js 和 webpack。它得到了 30 家企业和最终用户成员的支持，包括 GoDaddy、Google、IBM、Intel、Joyent 和 Microsoft。Electron 是一个使用 Web 技术构建跨平台桌面应用程序的开源框架。

这对 Electron 来说是一个令人兴奋的举措，我们认为这是我们作为开源项目发展的下一步。

这对开发者意味着什么​

Electron 加入 OpenJS 基金会并不会改变 Electron 的开发、发布或使用方式——也不会直接影响使用 Electron 开发应用程序的开发者。尽管 Electron 最初于 2013 年在 GitHub 上创建，但目前它由许多组织和个人维护。2019 年，Electron 规范化了其治理结构，并大力投入正式化影响整个项目的决策制定方式。我们相信，多个组织和开发者的投入和协作将使 Electron 项目更加强大。

将 Electron 从单一企业实体所有，转移到一个专注于支持 Web 和 JavaScript 生态系统的中立基金会，是我们作为开源项目成熟过程中的一个自然而然的下一步。

了解更多​

您可以在 OpenJSF 网站上了解该基金会、其使命和成员。有关 Electron 被接纳加入 OpenJSF 孵化项目的更多信息和引言，请查看官方新闻稿。要了解更多关于 Electron 背后的开发者以及他们如何协作，请参阅我们的 治理页面。

要开始使用 Electron 本身，请查看 我们的文档。

Chromium 中发现了一个高危漏洞，该漏洞影响包括 Electron 在内的所有基于 Chromium 的软件。

此漏洞已被分配 CVE-2019-13720。您可以在 Chrome 博客文章中阅读更多相关信息。

请注意，Chrome 报告称此漏洞已在野外被利用，因此强烈建议您尽快升级 Electron。

范围​

这会影响任何可能运行第三方或不受信任的 JavaScript 的 Electron 应用程序。

缓解措施​

受影响的应用应升级到已修复的 Electron 版本。

我们已发布新版本的 Electron，其中包含此漏洞的修复程序。

• 6.1.4

Electron 7.0.1 在公告发布前已自动包含来自上游的修复。Electron 8 同样不受影响。该漏洞在 Electron 5 中不存在，因此该版本也不受影响。

进一步信息​

此漏洞由卡巴斯基实验室的 Anton Ivanov 和 Alexey Kulaev 发现，并报告给 Chrome 团队。Chrome 博客文章可在此处找到：此处。

要了解有关保护您的 Electron 应用安全的最佳实践，请参阅我们的安全教程。

如果您希望报告 Electron 中的漏洞，请提交 GitHub 安全咨询。

Electron 7.0.0 已发布！ 此版本中包含了对 Chromium 78、V8 7.8 和 Node.js 12.8.1 的升级。 我们增加了适用于 Arm 64 的 Windows 版本，更快的 IPC 方法，一个新的 `nativeTheme` API，以及更多！

Electron 团队很高兴地宣布 Electron 7.0.0 发布！您可以通过 npm install electron@latest 使用 npm 安装，或从我们的发布网站下载。此版本包含大量升级、修复和新功能。我们迫不及待地想看看您会用它们构建出什么！请继续阅读以获取有关此版本的详细信息，并请分享您的任何反馈！

重要变更​

• 技术栈升级

  技术栈	Electron 6 中的版本	Electron 7 中的版本	新功能
  Chromium	76.0.3809.146	78.0.3905.1	77, 78
  V8	7.6	7.8	7.7, 7.8
  Node.js	12.4.0	12.8.1	12.5, 12.6, 12.7, 12.8, 12.8.1

• 新增 Windows on Arm (64 位) 版本。#18591, #20112

• 新增 ipcRenderer.invoke() 和 ipcMain.handle() 用于异步请求/响应式 IPC。强烈建议使用这些模块替代 remote 模块。有关更多信息，请参阅这篇名为“Electron 的“remote”模块被认为有害”的博客文章。#18449

• 新增 nativeTheme API，用于读取和响应操作系统主题和配色方案的变化。#19758, #20486

• 切换到新的 TypeScript 定义生成器。生成的定义更精确；因此如果您的 TypeScript 构建失败，这很可能是原因。#18103

请参阅 7.0.0 版本说明获取更完整的更新列表。

破坏性变更​

关于这些以及未来变更的更多信息，可以在计划中的重大变更页面找到。

• 已移除废弃的 API
  • 现在使用 Promise 的函数的基于回调的版本。 #17907
  • Tray.setHighlightMode() (macOS)。 #18981
  • app.enableMixedSandbox() #17894
  • app.getApplicationMenu(),
  • app.setApplicationMenu(),
  • powerMonitor.querySystemIdleState(),
  • powerMonitor.querySystemIdleTime(),
  • webFrame.setIsolatedWorldContentSecurityPolicy(),
  • webFrame.setIsolatedWorldHumanReadableName(),
  • webFrame.setIsolatedWorldSecurityOrigin() #18159
• Session.clearAuthCache() 不再允许筛选要清除的缓存条目。 #17970
• macOS 上的原生界面（菜单、对话框等）现在会自动匹配用户机器上的暗黑模式设置。 #19226
• 更新了 `electron` 模块以使用 `@electron/get`。 最低支持的 Node 版本现在是 Node 8。 #18413
• 文件 `electron.asar` 已不存在。 任何依赖于其存在的打包脚本都应进行更新。 #18577

结束对 4.x.y 的支持​

根据项目的支持政策，Electron 4.x.y 已达到支持终止。建议开发人员和应用程序升级到较新的 Electron 版本。

应用反馈计划​

我们将继续使用我们的应用程序反馈计划进行测试。参与该计划的项目会在其应用程序上测试 Electron Beta 版本；作为回报，他们发现的新 Bug 将优先在稳定版本中修复。如果您想参与或了解更多信息，请查看我们关于该计划的博客文章。

下一步计划​

短期内，您可以期待团队继续专注于跟上构成 Electron 的主要组件（包括 Chromium、Node 和 V8）的开发。尽管我们谨慎地不承诺发布日期，但我们的计划是大约每季度发布一个新的 Electron 主要版本，其中包含这些组件的新版本。暂定的 8.0.0 发布时间表列出了 Electron 8 开发生命周期中的关键日期。此外，请参阅我们的版本控制文档，了解有关 Electron 版本控制的更多详细信息。

有关 Electron 未来版本中计划的重大变更信息，请参阅我们的“计划中的重大变更”文档。

Electron 团队很高兴地宣布 Electron 6.0.0 发布！您可以通过 npm install electron@latest 使用 npm 进行安装，或者从我们的 发布网站 下载。此次发布包含大量的升级、修复和新功能。我们迫不及待地想看到您利用它们构建出什么！请继续阅读有关此次发布的详细信息，并分享您的任何反馈！

新增内容​

今天标志着 Electron 项目的一个首次：这是我们第一次在与相应的 Chrome 稳定版发布的同一天发布稳定的 Electron 版本！🎉

Electron 的大部分功能由 Chromium、Node.js 和 V8 的核心组件提供。Electron 会及时更新这些项目，为用户提供新的 JavaScript 功能、性能改进和安全修复。在 Electron 6 中，这些包中的每一个都经历了主版本号的提升。

• Chromium 76.0.3809.88
  • 74 版本新增
  • 75 版本新增
  • 76 版本新增
• Node.js 12.4.0
  • Node 12.4.0 博客文章
• V8 7.6.303.22
  • V8 7.6 博客文章

本次发布还包括对 Electron API 的改进。发布说明中有更完整的列表，但以下是亮点：

Promises 化​

Electron 6.0 继续了 5.0 中启动的 现代化 Promise 支持改进计划。

这些函数现在返回 Promises，并且仍然支持旧的基于回调的调用方式。

• contentTracing.getCategories() #16583
• contentTracing.getCategories() #16583
• contentTracing.getTraceBufferUsage() #16600
• contents.executeJavaScript() #17312
• cookies.flushStore() #16464
• cookies.get() #16464
• cookies.remove() #16464
• cookies.set() #16464
• dialog.showCertificateTrustDialog() #17181
• inAppPurchase.getProducts() #17355
• inAppPurchase.purchaseProduct()#17355
• netLog.stopLogging() #16862
• session.clearAuthCache() #17259
• session.clearCache() #17185
• session.clearHostResolverCache() #17229
• session.clearStorageData() #17249
• session.getBlobData() #17303
• session.getCacheSize() #17185
• session.resolveProxy() #17222
• session.setProxy() #17222
• webContents.hasServiceWorker() #16535
• webContents.printToPDF() #16795
• webContents.savePage() #16742
• webFrame.executeJavaScript() #17312
• webFrame.executeJavaScriptInIsolatedWorld() #17312
• webviewTag.executeJavaScript() #17312

这些函数现在有两种形式：同步和基于 Promise 的异步。

• dialog.showMessageBox()/dialog.showMessageBoxSync() #17298
• dialog.showOpenDialog()/dialog.showOpenDialogSync() #16973
• dialog.showSaveDialog()/dialog.showSaveDialogSync() #17054

这些函数现在返回 Promises。

• app.dock.show() #16904

Electron Helper (Renderer).app、Electron Helper (GPU).app 和 Electron Helper (Plugin).app​

为了启用 硬化运行时（它限制了可写可执行内存和加载由不同 Team ID 签名的代码等），必须为 Helper 授予特殊的代码签名权限。

为了将这些权限限定在需要它们的进程类型上，Chromium 添加了了 Helper 应用的三个新变体：一个用于渲染器（Electron Helper (Renderer).app），一个用于 GPU 进程（Electron Helper (GPU).app），还有一个用于插件（Electron Helper (Plugin).app）。

使用 electron-osx-sign 对其 Electron 应用进行代码签名的开发者应该无需对其构建逻辑进行任何更改。如果您使用自定义脚本对应用进行代码签名，则应确保这三个新的 Helper 应用已正确进行代码签名。

为了使用这些新的 Helper 应用正确打包您的应用，您需要使用 electron-packager@14.0.4 或更高版本。如果您正在使用 electron-builder，则应关注 此 issue 以跟踪对这些新 Helper 的支持。

破坏性变更​

• 此次发布开始为未来要求渲染进程中加载的本地 Node 模块必须是 N-API 或 Context Aware 打下基础。此更改的原因是为了提高性能、增强安全性并减轻维护负担。在 此 issue 中阅读包括拟议时间表在内的全部详细信息。此更改预计将在 Electron v11 中完成。

• net.IncomingMessage 的 headers 略有变化，以更紧密地匹配 Node.js 的行为，特别是在 set-cookie 的值以及如何处理重复的 headers 方面。#17517。

• shell.showItemInFolder() 现在返回 void 并且是一个异步调用。#17121

• 应用程序现在必须在调用新函数 app.setAppLogPath() 来设置日志路径后，才能使用 app.getPath('log')。 #17841

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

根据我们的 支持策略，3.x.y 系列已达到生命周期终点。鼓励开发者和应用程序升级到更新版本的 Electron。

应用反馈计划​

我们将继续使用我们的应用程序反馈计划进行测试。参与该计划的项目会在其应用程序上测试 Electron Beta 版本；作为回报，他们发现的新 Bug 将优先在稳定版本中修复。如果您想参与或了解更多信息，请查看我们关于该计划的博客文章。

下一步计划​

短期内，您可以期望团队继续专注于跟上构成 Electron 的主要组件（包括 Chromium、Node 和 V8）的开发。尽管我们谨慎对待发布日期，但我们的计划是大约每季度发布一次包含这些组件新版本的新版 Electron。 7.0.0 计划表 概述了 Electron 7 开发生命周期中的关键日期。此外，请参阅我们的 版本文档 以获取有关 Electron 中版本管理的更详细信息。

有关 Electron 未来版本中计划的重大变更信息，请参阅我们的“计划中的重大变更”文档。

🎉 Electron 将转为每 12 周发布一个新的主稳定版本！🎉

⚡️ 哇，好快！但为什么呢？​

简而言之，Chromium 不会停止发布，所以 Electron 也不会放慢脚步。

Chromium 以稳定的 6 周日程发布。为了在 Electron 中提供最新版本的 Chromium，我们的日程需要跟上他们的节奏。有关 Chromium 发布周期的更多信息，请在此处查找。

🚀 为什么是每 12 周？​

每 6 周，一个新的 Chromium 版本就会发布，其中包含新功能、错误修复/安全修复以及 V8 改进。Electron 的用户一直明确表示希望及时获得这些更改，因此我们调整了稳定版发布日期，以匹配每隔一次的 Chromium 稳定版发布。首先，Electron v6.0.0 将包含 M76，并计划于 2019 年 7 月 30 日稳定发布，与 Chromium M76 同一个发布日。

🚧 这对我以及我的 Electron 应用意味着什么？​

您将比以前更快地获得新的 Chromium 和 V8 的功能与修复。重要的是，您还将知道这些新变更何时到来，从而能够根据更准确的信息进行规划。

Electron 团队将继续支持最新的三个主要版本。例如，当v6.0.0 于 2019 年 7 月 30 日稳定发布时，我们将支持 v6.x、v5.x 和 v4.x，而 v3.x 将达到生命周期结束 (End-Of-Life)。

💬 应用反馈计划​

请考虑加入我们的应用反馈计划，以帮助我们测试 beta 版本和稳定化。参与此计划的项目在其应用程序上测试 Electron beta 版本；作为回报，他们发现的新错误将优先在稳定版本中修复。

📝 Electron 发布简史​

v3.0.0 之前的稳定版本发布没有遵循既定的时间表。我们在 v3.0.0 和 v4.0.0 版本中为项目增加了内部时间表。今年早些时候，我们首次为Electron v5.0.0 公布了稳定版发布日期。总体而言，公布稳定版发布日期收到了积极的反馈，我们很高兴在未来的版本中继续这样做。

为了更好地协调这些升级相关的工作，我们在治理系统中创建了升级和发布工作组。它们使我们能够更好地确定这些工作的优先级并进行委派，我们希望这将随着每个后续版本的发布而更加明显。

以下是我们的新周期与 Chromium 周期的对比情况

📨 如果您有任何问题，请发送邮件至 info@electronjs.org。

Electron 团队很高兴地宣布 Electron 5.0.0 的发布！您可以通过 npm install electron@latest 使用 npm 进行安装，或从 我们的发布页面 下载 tarball。本次发布包含大量的升级、修复和新功能。我们迫不及待地想看到您用它们构建出什么！请继续阅读以了解本次发布的详细信息，并欢迎分享您的任何反馈！

有什么新内容？​

Electron 的大部分功能由 Chromium、Node.js 和 V8 的核心组件提供。Electron 会及时跟进这些项目的最新进展，为用户提供新的 JavaScript 功能、性能改进和安全修复。在 Electron 5 中，所有这些包都进行了主版本升级。

• Chromium 73.0.3683.119
  • 70 版本中的新内容
  • 71 版本中的新内容
  • 72 版本中的新内容
  • 73 版本中的新内容
• Node.js 12.0.0
  • Node 12 博客文章
• V8 7.3.492.27。
  • 新的 JavaScript 功能

Electron 5 还包括对 Electron 特有 API 的改进。主要更改的摘要如下；有关完整更改列表，请查看 Electron v5.0.0 发布说明。

Promises 化​

Electron 5 继续了 Promisification initiative（Promise 化计划），将 Electron 基于回调的 API 转换为使用 Promise。这些 API 在 Electron 5 中已完成转换。

• app.getFileIcon
• contentTracing.getCategories
• contentTracing.startRecording
• contentTracing.stopRecording
• debugger.sendCommand
• Cookies API
• shell.openExternal
• webContents.loadFile
• webContents.loadURL
• webContents.zoomLevel
• webContents.zoomFactor
• win.capturePage

macOS 系统颜色访问​

以下函数已更改或添加到 systemPreferences 中，用于访问 macOS 系统的颜色：

• systemPreferences.getAccentColor
• systemPreferences.getColor
• systemPreferences.getSystemColor

进程内存信息​

已添加 process.getProcessMemoryInfo 函数，用于获取当前进程的内存使用情况统计信息。

远程 API 的附加过滤​

为了提高 remote API 的安全性，添加了新的 remote 事件，以便 remote.getBuiltin、remote.getCurrentWindow、remote.getCurrentWebContents 和 <webview>.getWebContents 可以被 过滤。

BrowserWindow 上的多个 BrowserViews​

BrowserWindow 现在支持在同一个 BrowserWindow 中管理多个 BrowserViews。

破坏性变更​

打包应用程序的默认设置​

打包应用程序现在将与默认应用程序的行为相同：将创建一个默认的应用程序菜单，除非应用程序已有菜单并且 window-all-closed 事件将被自动处理，除非应用程序已处理该事件。

混合沙箱​

混合沙箱模式现在默认启用。使用 sandbox: true 启动的渲染器现在将真正进行沙箱化，而以前只有在启用混合沙箱模式时才会进行沙箱化。

安全改进​

为了提高安全性，nodeIntegration 和 webviewTag 的默认值现在为 false。

拼写检查器现在是异步的​

SpellCheck API 已更改为提供 异步结果。

弃用​

以下 API 在 Electron 5.0.0 中已弃用，并计划在 6.0.0 中移除：

arm 和 arm64 的 Mksnapshot 二进制文件​

arm 和 arm64 的 mksnapshot 原生二进制文件已弃用，并将于 6.0.0 中移除。可以使用 x64 二进制文件为 arm 和 arm64 创建快照。

WebContents 上的 ServiceWorker API​

为准备移除，WebContents 上的 ServiceWorker API 已弃用。

• webContents.hasServiceWorker
• webContents.unregisterServiceWorker

带沙盒 WebContents 的自动模块​

为了提高安全性，以下模块通过 require 直接使用的行为已被弃用，在沙箱化的 WebContents 中需要通过 remote.require 来包含：

• electron.screen
• child_process
• fs
• os
• path

webFrame 隔离世界 API​

webFrame.setIsolatedWorldContentSecurityPolicy、webFrame.setIsolatedWorldHumanReadableName、webFrame.setIsolatedWorldSecurityOrigin 已弃用，改用 webFrame.setIsolatedWorldInfo。

混合沙箱​

enableMixedSandbox 和命令行开关 --enable-mixed-sandbox 仍然存在以兼容，但它们已被弃用且无效。

停止支持 2.0.x​

根据我们的 支持版本策略，2.0.x 已达到生命周期终点。

应用反馈计划​

我们将继续使用我们的应用程序反馈计划进行测试。参与该计划的项目会在其应用程序上测试 Electron Beta 版本；作为回报，他们发现的新 Bug 将优先在稳定版本中修复。如果您想参与或了解更多信息，请查看我们关于该计划的博客文章。

下一步计划​

短期内，您可以预期团队将继续专注于跟进构成 Electron 的主要组件（包括 Chromium、Node 和 V8）的开发。虽然我们不会承诺发布日期，但我们的计划是大约每季度发布一个包含这些组件新版本的 Electron 新主版本。 Electron 6.0.0 的暂定计划 概述了 Electron 6 开发生命周期中的关键日期。此外，请参阅我们的 版本文档，以获取有关 Electron 版本管理的更详细信息。

有关 Electron 未来版本中计划的重大变更信息，请参阅我们的“计划中的重大变更”文档。

Electron 中用 C++ 或 Objective-C 编写的功能是如何被暴露给 JavaScript，从而可供最终用户使用的？

背景​

Electron 是一个 JavaScript 平台，其主要目的是降低开发者构建强大桌面应用的门槛，无需担心特定于平台的实现。然而，Electron 本身的核心仍然需要用给定系统语言编写特定于平台的功能。

实际上，Electron 会为你处理原生代码，这样你就可以专注于单一的 JavaScript API。

但这又是如何工作的呢？Electron 中用 C++ 或 Objective-C 编写的功能是如何被暴露给 JavaScript，从而可供最终用户使用的？

要追踪这个路径，让我们从 app 模块开始。

通过打开我们 lib/ 目录中的 app.ts 文件，您会在顶部找到以下代码行

const binding = process.electronBinding('app');

这行代码直接指向 Electron 将其 C++/Objective-C 模块绑定到 JavaScript 以供开发者使用的机制。此函数由 ElectronBindings 类的头文件和实现文件创建。

process.electronBinding​

这些文件添加了 process.electronBinding 函数，其行为类似于 Node.js 的 process.binding。 process.binding 是 Node.js require() 方法的较低级别实现，只不过它允许用户 require 原生代码而不是用 JS 编写的其他代码。这个自定义的 process.electronBinding 函数赋予了从 Electron 加载原生代码的能力。

当一个顶层 JavaScript 模块（如 app）需要这个原生代码时，该原生代码的状态是如何确定的和设置的？方法是如何暴露给 JavaScript 的？属性呢？

native_mate​

目前，这个问题的答案可以在 native_mate 中找到：它是 Chromium gin 库的一个分支，它使得在 C++ 和 JavaScript 之间整理类型变得更容易。

在 native_mate/native_mate 内部有一个 object_template_builder 的头文件和实现文件。这允许我们以原生代码的形式构建模块，其结构符合 JavaScript 开发者的预期。

mate::ObjectTemplateBuilder​

如果我们把每个 Electron 模块都看作一个 object，就更容易理解为什么要使用 object_template_builder 来构建它们。这个类是基于 V8 暴露的一个类构建的，V8 是谷歌的开源高性能 JavaScript 和 WebAssembly 引擎，用 C++ 编写。V8 实现了 JavaScript (ECMAScript) 规范，因此其原生功能实现可以直接与 JavaScript 中的实现关联。例如，v8::ObjectTemplate 为我们提供了没有专用构造函数和原型的 JavaScript 对象。它使用 Object[.prototype]，在 JavaScript 中等同于 Object.create()。

要查看实际操作，请查看 app 模块的实现文件，atom_api_app.cc。底部有以下内容

mate::ObjectTemplateBuilder(isolate, prototype->PrototypeTemplate())
    .SetMethod("getGPUInfo", &App::GetGPUInfo)

在上面一行中，在 mate::ObjectTemplateBuilder 上调用了 .SetMethod。 .SetMethod 可以在 ObjectTemplateBuilder 类的任何实例上调用，以在 JavaScript 中的对象原型上设置方法，语法如下

.SetMethod("method_name", &function_to_bind)

这是 JavaScript 中等价于

function App{}
App.prototype.getGPUInfo = function () {
  // implementation here
}

这个类还包含用于在模块上设置属性的函数

.SetProperty("property_name", &getter_function_to_bind)

或

.SetProperty("property_name", &getter_function_to_bind, &setter_function_to_bind)

这些将反过来是 Object.defineProperty 的 JavaScript 实现

function App {}
Object.defineProperty(App.prototype, 'myProperty', {
  get() {
    return _myProperty
  }
})

和

function App {}
Object.defineProperty(App.prototype, 'myProperty', {
  get() {
    return _myProperty
  }
  set(newPropertyValue) {
    _myProperty = newPropertyValue
  }
})

可以创建由原型和属性组成的 JavaScript 对象，就像开发者期望的那样，并且可以更清晰地推理出在这个较低系统级别实现的功能和属性！

关于在哪里实现任何给定模块方法的决定本身是一个复杂且常常是非确定性的问题，我们将在未来的帖子中介绍。

随着 Electron 在桌面应用程序中越来越受欢迎，开发团队也随之壮大：我们拥有更多来自不同公司、居住在不同时区、拥有不同兴趣的全职维护者。我们正在引入一种治理结构，以便我们能够持续平稳地发展。

为什么会发生改变？​

Electron 项目中的人员与世界各地的志愿者、全职维护者以及数家依赖 Electron 的公司进行跨时区协调。到目前为止，我们一直通过非正式协调取得了成功；但随着团队的壮大，我们发现这种方法无法扩展。我们还希望让新的贡献者更容易在项目中找到归属感。

工作组​

Electron 的治理结构包含了负责项目不同部分的工作组。我们首先设立了七个小组：

• 社区与安全 (Community & Safety)：处理行为准则相关问题。
• 文档和工具：负责面向外部的工具（例如 Fiddle、Forge）和 Electron 文档。
• 外联 (Outreach)：帮助发展 Electron 社区。
• 发布 (Releases)：确保版本发布稳定且准时。
• 安全 (Security)：进行安全测试并响应安全问题。
• 升级 (Upgrades)：整合上游更新，例如新版本的 V8、Chromium 和 Node。
• 网站 (Website)：维护和改进 Electron 网站。

这些工作组将相互协调，但每个工作组都有自己的会议日程和议程，以独立高效地运作。有关这些工作组的更多详细信息，请访问治理仓库。

这会改变 Electron 项目的方向吗？​

这不应该对 Electron 的方向产生任何直接影响。如果我们的策略成功，工作组将使新的贡献者更容易找到他们感兴趣的话题，并通过将与他们日常工作无关的讨论转移到其他工作组，从而简化维护者的生活。如果发生这种情况，通过更多未受阻碍的人协同工作，可能会间接影响事物。

我可以在哪里了解更多信息？​

• 治理仓库和章程中包含有关新治理结构的信息。
• 每个工作组都有自己的页面：社区、文档与工具、外展、发布、安全、升级和网站。
• 您可以通过提出问题或发送邮件至 info@electronjs.org 联系维护者。

Chromium 中发现了一个高危漏洞，该漏洞影响包括 Electron 在内的所有基于 Chromium 的软件。

此漏洞已被分配 CVE-2019-5786。您可以在 Chrome 博客文章中了解更多信息。

请注意，Chrome 已收到此漏洞在野外被利用的报告，因此强烈建议您尽快升级 Electron。

范围​

这会影响任何可能运行第三方或不受信任的 JavaScript 的 Electron 应用程序。

缓解措施​

受影响的应用应升级到已修复的 Electron 版本。

我们已发布新版本的 Electron，其中包含此漏洞的修复程序。

• 4.0.8
• 3.1.6
• 3.0.16
• 2.0.18

Electron 5 的最新测试版已跟随 Chromium 73，因此已得到修复。

• 5.0.0-beta.5

进一步信息​

此漏洞由 Google 威胁分析小组的 Clement Lecigne 发现并报告给 Chrome 团队。Chrome 博客文章可以在 此处找到。

要了解有关保护您的 Electron 应用安全的最佳实践，请参阅我们的安全教程。

如果您希望报告 Electron 中的漏洞，请提交 GitHub 安全咨询。

Electron 团队将于 Electron v4.0 起停止对 32 位 Linux (ia32 / i386) 的支持。最后一个支持 32 位 Linux 安装的 Electron 版本是 Electron v3.1，该版本将一直获得支持版本更新，直到 Electron v6 发布。对 64 位 Linux 和 armv7l 的支持将保持不变。

Electron 具体将不再支持什么？​

您可能在电脑的贴纸上或下载软件的选项中看到过“64 位”和“32 位”的描述。这个术语用来描述一种特定的计算机架构。20 世纪 90 年代和 21 世纪初的大部分计算机都基于 32 位架构的 CPU 制造，而之后的大部分计算机则基于更新、更强大的 64 位架构。任天堂 64（明白了吗？）和 PlayStation 2 是首批广泛普及的新架构消费级设备，2010 年后销售的计算机几乎完全采用 64 位处理器。因此，支持正在不断减少：Google 于 2016 年 3 月停止发布 32 位 Linux 版 Chrome，Canonical 于 2017 年停止提供 32 位桌面镜像，并在 Ubuntu 18.10 中完全放弃了对 32 位版本的支持。Arch Linux、elementary OS 以及其他主流 Linux 发行版也已放弃对老旧处理器架构的支持。

到目前为止，Electron 一直提供并支持可在旧 32 位架构上运行的构建。从 v4.0 版本开始，Electron 团队将不再为 32 位 Linux 提供二进制文件或支持。

Electron 一直是一个充满活力的开源项目，我们将继续支持并鼓励有兴趣为特定架构构建 Electron 的开发者。

这对开发者意味着什么？​

如果您目前不为 Linux 提供您应用程序的 32 位分发版，则无需采取任何操作。

发布 32 位 Linux Electron 应用程序的项目需要决定如何进行。Electron 3 将在 Electron 6 发布之前支持 32 位 Linux，这为做出决定和制定计划提供了一些时间。

这对用户意味着什么？​

如果您是 Linux 用户，并且不确定自己是否运行的是 64 位系统，那么您很可能使用的是 64 位架构。要确定这一点，您可以在终端中运行 lscpu 或 uname -m 命令。这两个命令都会输出您当前的架构。

如果您在 32 位处理器上使用 Linux，您很可能已经遇到了为您的操作系统寻找最新发布软件的困难。Electron 团队与其他 Linux 社区的重要成员一样，建议您升级到 64 位架构。