跳转到主内容

Chromium FileReader Vulnerability Fix

· 阅读时间:约 1 分钟

A High severity vulnerability has been discovered in Chrome which affects all software based on Chromium, including Electron.

此漏洞已被分配 CVE-2019-5786。 You can read more about it in the Chrome Blog Post.

Please note that Chrome has reports of this vulnerability being used in the wild so it is strongly recommended you upgrade Electron ASAP.


作用域

This affects any Electron application that may run third-party or untrusted JavaScript.

Mitigation

Affected apps should upgrade to a patched version of Electron.

We've published new versions of Electron which include fixes for this vulnerability:

The latest beta of Electron 5 was tracking Chromium 73 and therefore is already patched:

Further Information

This vulnerability was discovered by Clement Lecigne of Google's Threat Analysis Group and reported to the Chrome team. The Chrome blog post can be found here.

要了解更多关于维护您的 Electron 应用安全的最佳做法,请参阅我们的 安全教程

If you wish to report a vulnerability in Electron, email security@electronjs.org.

不再支持32位Linux

· 阅读时间:约 3 分钟

Electron 团队将停止支持 32 位 Linux (ia32 / i386),从Electron v4.0 开始。 支持基于32位的 Linux 安装的 Electron 最后版本是 Electron v3.1,它将获得支持版本直到Electron v6 被解除。 Support for 64-bit based Linux and armv7l will continue unchanged.


What exactly is Electron no longer supporting?

You may have seen the description "64-bit" and "32-bit" as stickers on your computer or as options for downloading software. The term is used to describe a specific computer architecture. Most computers made in the 1990s and early 2000s were made with CPUs that were based on the 32-bit architecture, while most computers made later were based on the newer and more powerful 64-bit architecture. The Nintendo 64 (get it?) and the PlayStation 2 were the first widely available consumer devices with the new architecture, computers sold after 2010 contained almost exclusively 64-bit processors. As a result, support has been shrinking: Google stopped releasing Chrome for 32-bit Linux in March 2016, Canonical stopped providing 32-bit desktop images in 2017 and dropped support for 32-bit altogether with Ubuntu 18.10. Arch Linux, elementary OS, and other prominent Linux distributions have already dropped support for the aging processor architecture.

Until now, Electron has provided and supported builds that run on the older 32-bit architecture. From release v4.0 onwards, the Electron team will no longer be able to provide binaries or support for 32-bit Linux.

Electron has always been a vibrant open source project and we continue to support and encourage developers interested in building Electron for exotic architectures.

这对开发者意味着什么?

If you are not currently providing 32-bit distributions of your app for Linux, no action is required.

Projects which ship 32-bit Linux Electron applications will need to decide how to proceed. 32-bit Linux will be supported on Electron 3 until the release of Electron 6, which gives some time to make decisions and plans.

这对用户意味着什么?

If you are a Linux user and not sure whether or not you're running a 64-bit based system, you are likely running on a 64-bit based architecture. To make sure, you can run the lscpu or uname -m commands in your terminal. Either one will print your current architecture.

If you are using Linux on a 32-bit processor, you have likely already encountered difficulties finding recently released software for your operating system. The Electron team joins other prominent members in the Linux community by recommending that you upgrade to a 64-bit based architecture.

BrowserView window.open() 漏洞修复

· 阅读时间:约 2 分钟

已发现一个代码漏洞,允许在子窗口中重新启用 Node。


打开一个带有 sandbox: true 或者 nativeWindowOpen: truenodeIntegration: false 这些属性的 BrowserView ,将生成一个 webContents ,里面的window.open 方法可以被调用,同时新打开的子窗口将启用 nodeIntegration。 此漏洞会影响所有受支持的 Electron 版本。

Mitigation

We've published new versions of Electron which include fixes for this vulnerability: 2.0.17, 3.0.15, 3.1.3, 4.0.4, and 5.0.0-beta.2. 我们鼓励所有 Electron 开发者立即更新他们的应用程序到最新稳定版本。

如果由于某些原因,无法升级 Electron 版本,你可以通过禁用所有子网页内容来缓解这个问题:

view.webContents.on('-add-new-contents', (e) => e.preventDefault());

Further Information

此漏洞是由 PalmerAL发现并负责任地报告给Electron项目的。

要了解更多关于维护您的 Electron 应用安全的最佳做法,请参阅我们的 安全教程

If you wish to report a vulnerability in Electron, email security@electronjs.org.

Node.js Native Addons and Electron 5.0

· 阅读时间:约 2 分钟

If you're having trouble using a native Node.js addon with Electron 5.0, there's a chance it needs to be updated to work with the most recent version of V8.


Goodbye v8::Handle, Hello v8::Local

In 2014, the V8 team deprecated v8::Handle in favor of v8::Local for local handles. Electron 5.0 includes a version of V8 that has finally removed v8::Handle for good, and native Node.js addons that still use it will need to be updated before they can be used with Electron 5.0.

The required code change is minimal, but every native Node module that still uses v8::Handle will fail to build with Electron 5.0 and will need to be modified. The good news is that Node.js v12 will also include this V8 change, so any modules that use v8::Handle will need to be updated anyway to work with the upcoming version of Node.

I maintain a native addon, how can I help?

If you maintain a native addon for Node.js, ensure you replace all occurrences of v8::Handle with v8::Local. The former was just an alias of the latter, so no other changes need to be made to address this specific issue.

You may also be interested in looking into N-API, which is maintained separately from V8 as a part of Node.js itself, and aims to insulate native addons from changes in the underlying JavaScript engine. You can find more information in the N-API documentation on the Node.js website.

帮助! I use a native addon in my app and it won't work!

If you're consuming a native addon for Node.js in your app and the native addon will not build because of this issue, check with the author of the addon to see if they've released a new version that fixes the problem. If not, reaching out to the author (or opening a Pull Request!) is probably your best bet.

Electron v5.0.0 Timeline

· 阅读时间:约 2 分钟

Electron公司有史以来第一次很高兴从v5开始公布我们的发布时间表。 .0. 这是我们制定公开和长期时间表的第一步。


As mentioned in our v4.0.0 stable release blog post, we are planning to release approximately quarterly to maintain closer cadence with Chromium releases. Chromium releases a new version very quickly -- every 6 weeks.

Take a look at progression in Electron versus Chromium side-by-side:

line graph comparing Electron versus Chromium versions

In the last half of 2018, our top priority was releasing faster and catching up closer to Chromium. We succeeded by sticking to a predetermined timeline. Electron 3.0.0 and 4.0.0 were released in a 2-3 month timeline for each release. We are optimistic about continuing that pace in releasing 5.0.0 and beyond. With a major Electron release approximately every quarter, we're now keeping pace with Chromium's release cadence. Getting ahead of Chromium stable release is always a goal for us and we are taking steps towards that.

We would love to promise future dates like Node.js and Chromium do, but we are not at that place yet. We are optimistic that we will reach a long-term timeline in the future.

考虑到这一点,我们正在采取第一步,将我们的发布计划发布到v5.0.0。 您可以在这里找到

To help us with testing our beta releases and stabilization, please consider joining our App Feedback Program.

Electron 4.0.0

· 阅读时间:约 7 分钟

The Electron team is excited to announce that the stable release of Electron 4 is now available! You can install it from electronjs.org or from npm via npm install electron@latest. The release is packed with upgrades, fixes, and new features, and we can't wait to see what you build with them. Read more for details about this release, and please share any feedback you have as you explore!


What's New?

A large part of Electron's functionality is provided by Chromium, Node.js, and V8, the core components that make up Electron. As such, a key goal for the Electron team is to keep up with changes to these projects as much as possible, providing developers who build Electron apps access to new web and JavaScript features. To this end, Electron 4 features major version bumps to each of these components; Electron v4.0.0 includes Chromium 69.0.3497.106, Node 10.11.0, and V8 6.9.427.24.

In addition, Electron 4 includes changes to Electron-specific APIs. You can find a summary of the major changes in Electron 4 below; for the full list of changes, check out the Electron v4.0.0 release notes.

Disabling the remote Module

You now have the ability to disable the remote module for security reasons. The module can be disabled for BrowserWindows and for webview tags:

// BrowserWindow
new BrowserWindow({
webPreferences: {
enableRemoteModule: false
}
})

// webview tag
<webview src="http://www.google.com/" enableremotemodule="false"></webview>

See the BrowserWindow and <webview> Tag documentation for more information.

Filtering remote.require() / remote.getGlobal() Requests

This feature is useful if you don't want to completely disable the remote module in your renderer process or webview but would like additional control over which modules can be required via remote.require.

When a module is required via remote.require in a renderer process, a remote-require event is raised on the app module. You can call event.preventDefault() on the the event (the first argument) to prevent the module from being loaded. The WebContents instance where the require occurred is passed as the second argument, and the name of the module is passed as the third argument. The same event is also emitted on the WebContents instance, but in this case the only arguments are the event and the module name. In both cases, you can return a custom value by setting the value of event.returnValue.

// Control `remote.require` from all WebContents:
app.on('remote-require', function (event, webContents, requestedModuleName) {
// ...
});

// Control `remote.require` from a specific WebContents instance:
browserWin.webContents.on(
'remote-require',
function (event, requestedModuleName) {
// ...
},
);

In a similar fashion, when remote.getGlobal(name) is called, a remote-get-global event is raised. This works the same way as the remote-require event: call preventDefault() to prevent the global from being returned, and set event.returnValue to return a custom value.

// Control `remote.getGlobal` from all WebContents:
app.on(
'remote-get-global',
function (event, webContents, requrestedGlobalName) {
// ...
},
);

// Control `remote.getGlobal` from a specific WebContents instance:
browserWin.webContents.on(
'remote-get-global',
function (event, requestedGlobalName) {
// ...
},
);

For more information, see the following documentation:

JavaScript Access to the About Panel

On macOS, you can now call app.showAboutPanel() to programmatically show the About panel, just like clicking the menu item created via {role: 'about'}. See the showAboutPanel documentation for more information

Controlling WebContents Background Throttling

WebContents instances now have a method setBackgroundThrottling(allowed) to enable or disable throttling of timers and animations when the page is backgrounded.

let win = new BrowserWindow(...)
win.webContents.setBackgroundThrotling(启用BackgroundThrottling)
win.webContents.setBackgroundThrottling(enableBackgroundThrottling)

See the setBackgroundThrottling documentation for more information.

重大更改

No More macOS 10.9 Support

Chromium no longer supports macOS 10.9 (OS X Mavericks), and as a result Electron 4.0 and beyond does not support it either.

Single Instance Locking

Previously, to make your app a Single Instance Application (ensuring that only one instance of your app is running at any given time), you could use the app.makeSingleInstance() method. Starting in Electron 4.0, you must use app.requestSingleInstanceLock() instead. The return value of this method indicates whether or not this instance of your application successfully obtained the lock. If it failed to obtain the lock, you can assume that another instance of your application is already running with the lock and exit immediately.

For an example of using requestSingleInstanceLock() and information on nuanced behavior on various platforms, see the documentation for app.requestSingleInstanceLock() and related methods and the second-instance event.

win_delay_load_hook

When building native modules for windows, the win_delay_load_hook variable in the module's binding.gyp must be true (which is the default). If this hook is not present, then the native module will fail to load on Windows, with an error message like Cannot find module. See the native module guide for more information.

Deprecations

The following breaking changes are planned for Electron 5.0, and thus are deprecated in Electron 4.0.

Node.js Integration Disabled for nativeWindowOpen-ed Windows

Starting in Electron 5.0, child windows opened with the nativeWindowOpen option will always have Node.js integration disabled.

webPreferences Default Values

When creating a new BrowserWindow with the webPreferences option set, the following webPreferences option defaults are deprecated in favor of new defaults listed below:

PropertyDeprecated DefaultNew Default
contextIsolationfalsetrue
nodeIntegrationtruefalse
webviewTagvalue of nodeIntegration if set, otherwise truefalse

Please note: there is currently a known bug (#9736) that prevents the webview tag from working if contextIsolation is on. Keep an eye on the GitHub issue for up-to-date information!

Learn more about context isolation, Node integration, and the webview tag in the Electron security document.

Electron 4.0 will still use the current defaults, but if you don't pass an explicit value for them, you'll see a deprecation warning. To prepare your app for Electron 5.0, use explicit values for these options. See the BrowserWindow docs for details on each of these options.

webContents.findInPage(text[, options])

The medialCapitalAsWordStart and wordStart options have been deprecated as they have been removed upstream.

应用反馈项目

The App Feedback Program we instituted during the development of Electron 3.0 was successful, so we've continued it during the development of 4.0 as well. We'd like to extend a massive thank you to Atlassian, Discord, MS Teams, OpenFin, Slack, Symphony, WhatsApp, and the other program members for their involvement during the 4.0 beta cycle. To learn more about the App Feedback Program and to participate in future betas, check out our blog post about the program.

接下来

在短期内,您可以期待团队继续专注于跟上构成 Electron 的主要组件的开发,包括 Chromium、Node 和 V8。 尽管我们谨慎地避免对发布日期做出承诺,但我们的计划是大约每季度发布一次 Electron 的新主要版本以及这些组件的新版本。 关于 Electron 版本的更多详细信息,请看我们的 版本管理文档

For information on planned breaking changes in upcoming versions of Electron, see our Planned Breaking Changes doc.

SQLite Vulnerability Fix

· 阅读时间:约 1 分钟

A remote code execution vulnerability, "Magellan," has been discovered affecting software based on SQLite or Chromium, including all versions of Electron.


作用域

Electron applications using Web SQL are impacted.

Mitigation

Affected apps should stop using Web SQL or upgrade to a patched version of Electron.

We've published new versions of Electron which include fixes for this vulnerability:

There are no reports of this in the wild; however, affected applications are urged to mitigate.

Further Information

This vulnerability was discovered by the Tencent Blade team, who have published a blog post that discusses the vulnerability.

要了解更多关于维护您的 Electron 应用安全的最佳做法,请参阅我们的 安全教程

If you wish to report a vulnerability in Electron, email security@electronjs.org.

Electron App 反馈计划

· 阅读时间:约 4 分钟

Electron 正在努力使其发布周期更快和更稳定。 为了实现这个目标,我们对大范围的Electron应用使用App反馈计划,以此来测试beta版本和上报与应用相关的特定问题给Electron团队。 这有助于我们确定工作的优先次序,使应用程序能够更快地升级到我们的下一个稳定版本。

更改 (2020-05-21):该计划已经结束。


谁可以加入?

我们对应用加入此程序的标准和期望包含以下项目:

  • 在测试阶段通过10,000+用户使用时长测试您的应用程序
  • 拥有一个将每周与您讨论您应用程序中出现的Electron异常和应用拦截器的负责人
  • 您同意遵守Electron的行为守则
  • 您愿意分享下一个问题中列出的以下信息

我的Electron应用需要分享哪些信息?

  • 任何测试版应用程序为用户服务的总时长
  • 您的应用正在测试的 Electron 版本 (例如4.0.0-beta.3)
  • 任何正在测试的、会阻止应用程序升级到发布线的异常

用户时长

我们理解不是每个人都能分享准确的用户数字,但更好的数据帮助我们决定特定版本的稳定性。 我们要求应用承诺测试最低用户小时数,目前整个测试周期为10,000小时。

  • 10个用户小时可分为为10个用户各测试一小时,或一个用户测试10个小时
  • 您可以在测试版本之间分割测试,例如在3.0-beta测试的5,000个用户小时中。 然后在 3.0.0-β.5 测试5000个用户小时。 更多更好,但我们理解一些应用程序不能测试每个测试版本
  • CI 或 QA 小时数不计入总数,但是内部版本数不计。

我的 Electron 应用程序为什么要加入?

您的应用程序抛出的异常会被Electron核心队伍跟踪调查,并时刻获得此核心团队的注意力。 您的反馈有助于Electron团队了解新测试是如何进行的,以及需要完成哪些工作。

我的应用程序的信息是否会公开分享? 谁可以查看此信息?

不,您的应用程序的信息将不会与一般公众分享。 信息保存在一个私有的GitHub源代码库,只有应用反馈方案和 Electron Governance 的成员才能查看。 所有成员都同意遵循Electron的行为守则

注册

我们目前正在接受_有限的_注册申请。 如果您感兴趣并且能够满足上述要求,请填写此表格

Electron 3.0.0

· 阅读时间:约 4 分钟

The Electron team is excited to announce that the first stable release of Electron 3 is now available from electronjs.org and via npm install electron@latest! It's jam-packed with upgrades, fixes, and new features, and we can't wait to see what you build with them. Below are details about this release, and we welcome your feedback as you explore.


发布流程

As we undertook development of v3.0.0, we sought to more empirically define criteria for a stable release by formalizing the feedback progress for progressive beta releases. v3.0.0 would not have been possible without our App Feedback Program partners, who provided early testing and feedback during the beta cycle. Thanks to Atlassian, Atom, Microsoft Teams, Oculus, OpenFin, Slack, Symphony, VS Code, and other program members for their work. If you'd like to participate in future betas, please mail us at info@electronjs.org.

Changes / New Features

Major bumps to several important parts of Electron's toolchain, including Chrome v66.0.3359.181, Node v10.2.0, and V8 v6.6.346.23.

  • [#12656] feat: app.isPackaged
  • [#12652] feat: app.whenReady()
  • [#13183] feat: process.getHeapStatistics()
  • [#12485] feat: win.moveTop() to move window z-order to top
  • [#13110] feat: TextField and Button APIs
  • [#13068] feat: netLog API for dynamic logging control
  • [#13539] feat: enable webview in sandbox renderer
  • [#14118] feat: fs.readSync now works with massive files
  • [#14031] feat: node fs wrappers to make fs.realpathSync.native and fs.realpath.native available

Breaking API changes

  • [#12362] feat: updates to menu item order control
  • [#13050] refactor: removed documented deprecated APIs
    • See docs for more details
  • [#12477] refactor: removed did-get-response-details and did-get-redirect-request events
  • [#12655] feat: default to disabling navigating on drag/drop
  • [#12993] feat: Node v4.x or greater is required use the electron npm module
  • [#12008 #12140 #12503 #12514 #12584 #12596 #12637 #12660 #12696 #12716 #12750 #12787 #12858] refactor: NativeWindow
  • [#11968] refactor: menu.popup()
  • [#8953] feat: no longer use JSON to send the result of ipcRenderer.sendSync
  • [#13039] feat: default to ignore command line arguments following a URL
  • [#12004] refactor: rename api::Window to api::BrowserWindow
  • [#12679] feat: visual zoom now turned off by default
  • [#12408] refactor: rename app-command media-play_pause to media-play-pause

macOS

  • [#12093] feat: workspace notifications support
  • [#12496] feat: tray.setIgnoreDoubleClickEvents(ignore) to ignore tray double click events.
  • [#12281] feat: mouse forward functionality on macOS
  • [#12714] feat: screen lock / unlock events

Windows

  • [#12879] feat: added DIP to/from screen coordinate conversions

Nota Bene: Switching to an older version of Electron after running this version will require you to clear out your user data directory to avoid older versions crashing. You can get the user data directory by running console.log(app.getPath("userData")) or see docs for more details.

Bug Fixes

  • [#13397] fix: issue with fs.statSyncNoException throwing exceptions
  • [#13476, #13452] fix: crash when loading site with jquery
  • [#14092] fix: crash in net::ClientSocketHandle destructor
  • [#14453] fix: notify focus change right away rather not on next tick

MacOS

  • [#13220] fix: issue allowing bundles to be selected in <input file="type"> open file dialog
  • [#12404] fix: issue blocking main process when using async dialog
  • [#12043] fix: context menu click callback
  • [#12527] fix: event leak on reuse of touchbar item
  • [#12352] fix: tray title crash
  • [#12327] fix: non-draggable regions
  • [#12809] fix: to prevent menu update while it's open
  • [#13162] fix: tray icon bounds not allowing negative values
  • [#13085] fix: tray title not inverting when highlighted
  • [#12196] fix: Mac build when enable_run_as_node==false
  • [#12157] fix: additional issues on frameless windows with vibrancy
  • [#13326] fix: to set mac protocol to none after calling app.removeAsDefaultProtocolClient
  • [#13530] fix: incorrect usage of private APIs in MAS build
  • [#13517] fix: tray.setContextMenu crash
  • [#14205] fix: pressing escape on a dialog now closes it even if defaultId is set

Linux

  • [#12507] fix: BrowserWindow.focus() for offscreen windows

Other Notes

  • PDF Viewer is currently not working but is being worked on and will be functional once again soon
  • TextField and Button APIs are experimental and are therefore off by default
    • They can be enabled with the enable_view_api build flag

接下来

The Electron team continues to work on defining our processes for more rapid and smooth upgrades as we seek to ultimately maintain parity with the development cadences of Chromium, Node, and V8.

Using GN to Build Electron

· 阅读时间:约 3 分钟

Electron now uses GN to build itself. Here's a discussion of why.


GYP and GN

当Electron于2013年首次发布时,Chromium的构建配置是用 GYP编写的,短于“生成你的项目”。

2014年, Chromium项目引入了一个新的构建配置工具,叫做 GN (简称“生成 Ninja”),Chromium的构建文件被迁移到GN ,GYP 被从源代码中删除。

Electron 历史上一直保持主 Electron 代码libchromiumcontent之间的分离, 对 Chromium 的 'content' 子模块的 Electron 部分。 Electron has carried on using GYP, while libchromiumcontent -- as a subset of Chromium -- switched to GN when Chromium did.

Like gears that don't quite mesh, there was friction between using the two build systems. Maintaining compatibility was error-prone, from compiler flags and #defines that needed to be meticulously kept in sync between Chromium, Node, V8, and Electron.

To address this, the Electron team has been working on moving everything to GN. Today, the commit to remove the last of the GYP code from Electron was landed in master.

What this means for you

If you're contributing to Electron itself, the process of checking out and building Electron from master or 4.0.0 is very different than it was in 3.0.0 and earlier. See the GN build instructions for details.

If you're developing an app with Electron, there are a few minor changes you might notice in the new Electron 4.0.0-nightly; but more than likely, Electron's change in build system will be totally transparent to you.

What this means for Electron

GN is faster than GYP and its files are more readable and maintainable. Moreover, we hope that using a single build configuration system will reduce the work required to upgrade Electron to new versions of Chromium.

  • It's already helped development on Electron 4.0.0 substantially because Chromium 67 removed support for MSVC and switched to building with Clang on Windows. With the GN build, we inherit all the compiler commands from Chromium directly, so we got the Clang build on Windows for free!

  • It's also made it easier for Electron to use BoringSSL in a unified build across Electron, Chromium, and Node -- something that was problematic before.