在蒙特利尔举行的 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 本身，请查看 我们的文档。

Chrome 中发现了一个高严重性漏洞，它影响所有基于 Chromium 的软件，包括 Electron。

此漏洞已分配 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 中的漏洞，请发送电子邮件至 [email protected]。

Electron 7.0.0 已发布！它包括对 Chromium 78、V8 7.8 和 Node.js 12.8.1 的升级。我们添加了 Windows on Arm 64 版本、更快的 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

• 添加了用于异步请求/响应式 IPC 的 ipcRenderer.invoke() 和 ipcMain.handle()。强烈建议使用它们代替 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 测试版；作为回报，他们发现的新错误将被优先考虑用于稳定版本。如果您想参与或了解更多信息，请 查看我们关于该计划的博客文章。

下一步​

短期内，您可以期待团队继续专注于跟上构成 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 的改进。 发行说明 中提供了更完整的列表，但以下是一些重点

Promise 化​

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

这些函数现在返回 Promise，并且仍然支持较旧的基于回调的调用

• 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

这些函数现在返回 Promise

• app.dock.show() #16904

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

为了启用 强化运行时，该运行时会限制可写可执行内存和加载由不同团队 ID 签名的代码等操作，因此需要向 Helper 授予特殊的代码签名权限。

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

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

为了使用这些新的辅助函数正确打包您的应用程序，您需要使用[email protected]或更高版本。如果您使用的是electron-builder，则应遵循此问题以跟踪对这些新辅助函数的支持。

重大更改​

• 此版本开始为将来的需求奠定基础，即在渲染器进程中加载的原生 Node 模块必须是N-API或上下文感知的。进行此更改的原因是提高性能、增强安全性以及减少维护工作量。阅读此问题中包含的完整详细信息，包括拟议的时间表。预计此更改将在 Electron v11 中完成。

• net.IncomingMessage 标头已略有更改，以更紧密地匹配Node.js 行为，特别是set-cookie的值以及如何处理重复标头。#17517。

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

• 应用程序现在必须通过在使用app.getPath('log')之前调用新的函数app.setAppLogPath()来显式设置日志路径。#17841

3.x.y 版本结束支持​

根据我们的支持策略，3.x.y 版本已达到生命周期结束。鼓励开发人员和应用程序升级到 Electron 的较新版本。

应用反馈计划​

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

下一步​

在短期内，您可以预期团队将继续专注于跟上构成 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 将达到生命周期结束。

💬 应用程序反馈计划​

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

📝 Electron 版本发布简史​

v3.0.0 之前的稳定版本发布决策没有遵循时间表。我们在 v3.0.0 和 v4.0.0 中为项目添加了内部时间表。今年早些时候，我们决定首次公开发布Electron v5.0.0的稳定版本发布日期。宣布我们的稳定版本发布日期总体上得到了积极的回应，我们很高兴能够继续为未来的版本发布日期做同样的事情。

为了更好地简化这些与升级相关的努力，我们在我们的治理系统中创建了升级和发布工作组。它们使我们能够更好地优先处理和委派这项工作，我们希望这在每个后续版本中都会变得更加明显。

以下是我们的新发布节奏与 Chromium 发布节奏的比较。

📨 如有任何疑问，请发送邮件至[email protected]。

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

新增功能？​

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。
  • 新的 JS 功能

Electron 5 还包括对 Electron 特定 API 的改进。下面总结了主要更改；有关完整更改列表，请查看Electron v5.0.0 发行说明。

Promise 化​

Electron 5 继续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.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 测试版；作为回报，他们发现的新错误将被优先考虑用于稳定版本。如果您想参与或了解更多信息，请 查看我们关于该计划的博客文章。

下一步​

短期内，您可以期待团队继续专注于跟上构成 Electron 的主要组件（包括 Chromium、Node 和 V8）的开发。虽然我们谨慎地不对发布日期做出承诺，但我们的计划是大约每季度发布包含这些组件新版本的新主要版本的 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 是 Google 的开源高性能 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)

在上面的代码行中，.SetMethod 被调用到 mate::ObjectTemplateBuilder 上。.SetMethod 可以被调用到 ObjectTemplateBuilder 类的任何实例上，以在 JavaScript 中的Object 原型上设置方法，语法如下

.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 治理包括负责项目不同部分的工作组。我们从七个小组开始

• 社区与安全：处理行为准则问题。
• 文档与工具：监督面向外部的工具（例如Fiddle、Forge）和 Electron文档。
• 外联：帮助发展 Electron 社区。
• 发布：确保发布稳定并按计划进行。
• 安全：执行安全测试并响应安全问题。
• 升级：集成上游升级，例如 V8、Chromium 和 Node 的新版本。
• 网站：维护和改进Electron 网站。

这些小组将相互协调，但每个小组都有自己的会议时间表和议程，以便能够独立地提高工作效率。有关这些小组的更多详细信息，请访问治理存储库。

这是否改变了 Electron 项目的方向？​

这不会对 Electron 的方向产生任何直接影响。如果我们的策略成功，工作组将使新贡献者更容易找到他们感兴趣的主题，并通过将与他们日常工作无关的讨论转移到其他组来简化维护人员的工作。如果发生这种情况，它可能会通过让更多没有障碍的人一起工作来间接影响事情。

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

• 治理仓库和章程包含有关新治理结构的信息。
• 每个工作组都有自己的页面：社区、文档与工具、外联、发布、安全、升级和网站。
• 您可以通过提交问题或发送邮件至[email protected]联系维护人员。

Chrome 中发现了一个高严重性漏洞，它影响所有基于 Chromium 的软件，包括 Electron。

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

请注意，Chrome 已经报告此漏洞被用于实际攻击，因此强烈建议您尽快升级 Electron。

范围​

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

缓解措施​

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

我们已发布了包含此漏洞修复的新版本 Electron

• 4.0.8
• 3.1.6
• 3.0.16
• 2.0.18

Electron 5 的最新 Beta 版跟踪 Chromium 73，因此已修复此漏洞。

• 5.0.0-beta.5

更多信息​

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

要详细了解维护 Electron 应用安全的最佳实践，请参阅我们的 安全教程。

如果您想报告 Electron 中的漏洞，请发送电子邮件至 [email protected]。

从 Electron v4.0 开始，Electron 团队将停止支持 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 应用程序的项目需要决定如何继续。32 位 Linux 将在 Electron 3 上获得支持直到Electron 6 发布，这给出了做出决策和计划的时间。

这对用户意味着什么？​

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

如果您在 32 位处理器上使用 Linux，那么您可能已经遇到过难以找到针对您的操作系统的最新发布的软件的问题。Electron 团队加入了 Linux 社区的其他知名成员，建议您升级到基于 64 位的体系结构。