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

This vulnerability has been assigned CVE-2019-13720. Подробнее об этом можно прочитать в блоге Chrome.

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

Scope​

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:

• 6.1.4

Electron 7.0.1 automatically included the fix from upstream, before the announcement was made. Electron 8 is similarly unaffected. The vulnerability did not exist in Electron 5, so that version is also unaffected.

Further Information​

This vulnerability was discovered by Anton Ivanov and Alexey Kulaev at Kaspersky Labs and reported to the Chrome team. Запись в блоге Chrome находится здесь.

Чтобы узнать больше о лучших методах обеспечения безопасности приложений Electron, смотрите наш учебник по безопасности.

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

Electron 7.0.0 вышел! В него включены обновления до Chromium 78, V8 7.8 и Node.js 12.8.1. Мы добавили Windows на Arm 64, быстрый метод IPC, новую родную тему API и многое другое!

Команда Electron рада объявить о выпуске Electron 7.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. The release is packed with upgrades, fixes, and new features. We can't wait to see what you build with them! Continue reading for details about this release, and please share any feedback you have!

Notable Changes​

• Stack Upgrades:

  Stack	Version in Electron 6	Version in Electron 7	What's New
  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

• Added Windows on Arm (64 bit) release. #18591, #20112

• Added ipcRenderer.invoke() and ipcMain.handle() for asynchronous request/response-style IPC. These are strongly recommended over the remote module. See this "Electron’s ‘remote’ module considered harmful" blog post for more information. #18449

• Added nativeTheme API to read and respond to changes in the OS's theme and color scheme. #19758, #20486

• Switched to a new TypeScript Definitions generator. The resulting definitions are more precise; so if your TypeScript build fails, this is the likely cause. #18103

See the 7.0.0 release notes for a longer list of changes.

Критические изменения​

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

• Removed deprecated APIs:
  • Callback-based versions of functions that now use Promises. #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() no longer allows filtering the cleared cache entries. #17970
• Native interfaces on macOS (menus, dialogs, etc.) now automatically match the dark mode setting on the user's machine. #19226
• Updated the electron module to use @electron/get. The minimum supported node version is now Node 8. #18413
• The file electron.asar no longer exists. Any packaging scripts that depend on its existence should be updated. #18577

End of Support for 4.x.y​

Electron 4.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.

Программа отзывов​

We continue to use our App Feedback Program for testing. Projects who participate in this program test Electron betas on their apps; and in return, the new bugs they find are prioritized for the stable release. If you'd like to participate or learn more, check out our blog post about the program.

Что дальше​

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. Although we are careful not to make promises about release dates, our plan is release new major versions of Electron with new versions of those components approximately quarterly. The tentative 8.0.0 schedule maps out key dates in the Electron 8 development life cycle. Also, see our versioning document for more detailed information about versioning in Electron.

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

Команда Electron рада объявить о выпуске Electron 6.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. The release is packed with upgrades, fixes, and new features. We can't wait to see what you build with them! Continue reading for details about this release, and please share any feedback you have!

What's New​

Today marks a first for the Electron project: this is the first time we've made a stable Electron release on the same day as the corresponding Chrome stable release! 🎉

Much of Electron's functionality is provided by the core components of Chromium, Node.js, and V8. Electron keeps up-to-date with these projects to provide our users with new JavaScript features, performance improvements, and security fixes. Each of these packages has a major version bump in Electron 6:

• Chromium 76.0.3809.88
  • New in 74
  • New in 75
  • New in 76
• Node.js 12.4.0
  • Node 12.4.0 blog post
• V8 7.6.303.22
  • V8 7.6 blog post

This release also includes improvements to Electron's APIs. The release notes have a more complete list, but here are the highlights:

Promisification / Промисификация​

Electron 6.0 continues the modernization initiative started in 5.0 to improve Promise support.

These functions now return Promises and still support older callback-based invocation:

• 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

These functions now have two forms, synchronous and Promise-based asynchronous:

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

These functions now return Promises:

• app.dock.show() #16904

Electron Helper (Renderer).app, Electron Helper (GPU).app and Electron Helper (Plugin).app​

In order to enable the hardened runtime, which restricts things like writable-executable memory and loading code signed by a different Team ID, special code signing entitlements needed to be granted to the Helper.

To keep these entitlements scoped to the process types that require them, Chromium added three new variants of the Helper app: one for renderers (Electron Helper (Renderer).app), one for the GPU process (Electron Helper (GPU).app) and one for plugins (Electron Helper (Plugin).app).

Folks using electron-osx-sign to codesign their Electron app shouldn't have to make any changes to their build logic. If you're codesigning your app with custom scripts, you should ensure that the three new Helper applications are correctly codesigned.

In order to package your application correctly with these new helpers you need to be using electron-packager@14.0.4 or higher. If you are using electron-builder you should follow this issue to track support for these new helpers.

Критические изменения​

• This release begins laying the groundwork for a future requirement that native Node modules loaded in the renderer process be either N-API or Context Aware. The reasons for this change are faster performance, stronger security, and reduced maintenance workload. Read the full details including the proposed timeline in this issue. This change is expected to be completed in Electron v11.

• net.IncomingMessage headers have changed slightly to more closely match Node.js behavior, particularly with the value of set-cookie and how duplicate headers are handled. #17517.

• shell.showItemInFolder() now returns void and is an asynchronous call. #17121

• Apps must now explicitly set a log path by calling the new function app.setAppLogPath() before using app.getPath('log'). #17841

End of Support for 3.x.y​

Per our support policy, 3.x.y has reached end of life. Developers and applications are encouraged to upgrade to a newer version of Electron.

Программа отзывов​

We continue to use our App Feedback Program for testing. Projects who participate in this program test Electron betas on their apps; and in return, the new bugs they find are prioritized for the stable release. If you'd like to participate or learn more, check out our blog post about the program.

Что дальше​

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. Although we are careful not to make promises about release dates, our plan is release new major versions of Electron with new versions of those components approximately quarterly. The tentative 7.0.0 schedule maps out key dates in the Electron 7 development life cycle. Also, see our versioning document for more detailed information about versioning in Electron.

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

::info ⚡ Обновление (2021-07-14): Мы продвигаемся еще быстрее!

В 3 квартале 2021 года команда Chrome увеличила частоту выпуска с каждых 6 недель до каждых 4 недель. Релизы Electron последовали этому примеру. Пожалуйста, прочитайте обновленную 8-недельную каденцию сообщении в блоге для получения более актуальной информации!

:::

🎉 Electron собирается выпускать новую стабильную версию каждые 12 недель! 🎉

⚡️ Вау, это быстро! Но зачем?​

Проще говоря, Chromium не останавливает доставку, так что Electron тоже не собирается замедляться.

Релизы Chromium выпускаются в соответствии с 6-недельным графиком. To deliver the most up-to-date versions of Chromium in Electron, our schedule needs to track theirs. More information around Chromium's release cycle can be found here.

🚀 Почему каждые 12 недель?​

Каждые 6 недель выходит новый выпуск Chromium с новыми функциями, исправлениями ошибок/исправлениями безопасности и улучшениями V8. Пользователи Electron громко и ясно заявляли о своевременном внесении этих изменений, поэтому мы скорректировали даты выпуска стабильной версии, чтобы она соответствовала всем остальным стабильным выпускам Chromium. Во-первых, Electron v6.0.0 будет включать M76, и его стабильный выпуск запланирован на July 30, 2019, в тот же день выпуска, что и Chromium M76.

Что это значит для меня и моего приложения Electron?​

Вы получите доступ к новым функциям и исправлениям Chromium и V8 раньше, чем раньше. Главное, вы также будете знать когда грядут эти новые изменения, так что вы сможете планировать с большей информацией, чем раньше.

Команда Electron продолжит поддерживать последние три основные версии. Например, когда v6.0.0 станет стабильной 30 июля 2019 года, мы будем поддерживать v6.x, v5.x и v4.x, в то время как v3.x достигнет End-Of-Life.

💬 Программа отзывов​

Пожалуйста, рассмотрите возможность присоединиться к нашей Программе отзывов о приложениях чтобы помочь нам с тестированием наших бета-версий и стабилизацией. Projects who participate in this program test Electron betas on their apps; and in return, the new bugs they find are prioritized for the stable release.

Краткая история релизов Electron​

Решения относительно стабильных выпусков до v3.0.0 не следовали графику. В проект добавлены внутренние расписания v3.0.0 и v4.0.0. Ранее в этом году мы решили опубликовать наш стабильный релиз впервые в Electron v5.0.0. Объявление о датах выхода нашей стабильной версии было воспринято в целом положительно, и мы рады продолжить делать это для будущих выпусков.

Чтобы лучше оптимизировать эти усилия, связанные с обновлением, наши обновления и релизы рабочой группы были созданы в рамках нашей системы управление. Они позволили нам лучше расставить приоритеты и делегировать эту работу, что, как мы надеемся, станет более очевидным с каждым последующим выпуском.

Вот где наша новая каденция поставит нас по сравнению с каденцией Chromium:

📨 Если у вас есть вопросы, пожалуйста, напишите нам на info@electronjs.org.

Команда Electron рада объявить о выпуске Electron 5.0.0! You can install it with npm via npm install electron@latest or download the tarballs from our releases page. The release is packed with upgrades, fixes, and new features. We can't wait to see what you build with them! Continue reading for details about this release, and please share any feedback you have!

What's New?​

Much of Electron's functionality is provided by the core components of Chromium, Node.js, and V8. Electron keeps up-to-date with these projects to provide our users with new JavaScript features, performance improvements, and security fixes. Each of these packages has a major version bump in Electron 5:

• Chromium 73.0.3683.119
  • New in 70
  • New in 71
  • New in 72
  • New in 73
• Node.js 12.0.0
  • Node 12 Blog Post
• V8 7.3.492.27.
  • New JS Features

Electron 5 also includes improvements to Electron-specific APIs. A summary of the major changes is below; for the full list of changes, check out the Electron v5.0.0 release notes.

Promisification / Промисификация​

Electron 5 continues Promisification initiative initiative to convert Electron's callback-based API to use Promises. These APIs were converted for 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

System colors access for macOS​

These functions were changed or added to systemPreferences to access macOS systems' colors:

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

Process memory information​

The function process.getProcessMemoryInfo has been added to get memory usage statistics about the current process.

Additional filtering for remote APIs​

To improve security in the remote API, new remote events have been added so that remote.getBuiltin, remote.getCurrentWindow, remote.getCurrentWebContents and <webview>.getWebContents can be filtered.

Multiple BrowserViews on BrowserWindow​

BrowserWindow now supports managing multiple BrowserViews within the same BrowserWindow.

Критические изменения​

Defaults for packaged apps​

Packaged apps will now behave the same as the default app: a default application menu will be created unless the app has one and the window-all-closed event will be automatically handled unless the app handles the event.

Mixed sandbox​

Mixed sandbox mode is now enabled by default. Renderers launched with sandbox: true will now be actually sandboxed, where previously they would only be sandboxed if mixed-sandbox mode was also enabled.

Security improvements​

The default values of nodeIntegration and webviewTag are now false to improve security.

Spellchecker now asynchronous​

The SpellCheck API has been changed to provide asynchronous results.

Deprecations​

The following APIs are newly deprecated in Electron 5.0.0 and planned for removal in 6.0.0:

Mksnapshot binaries for arm and arm64​

Родные файлы mksnapshot для arm и arm64 устарели и будут удалены в 6. .0. Снимки могут быть созданы для arm и arm64 с помощью двоичных файлов x64.

ServiceWorker APIs on WebContents​

Deprecated ServiceWorker APIs on WebContents in preparation for their removal.

• webContents.hasServiceWorker
• webContents.unregisterServiceWorker

Automatic modules with sandboxed webContents​

In order to improve security, the following modules are being deprecated for use directly via require and will instead need to be included via remote.require in a sandboxed webcontents:

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

API webFrame изолированных миров​

webFrame.setIsolatedWorldContentSecurityPolicy,webFrame.setIsolatedWorldHumanReadableName, webFrame.setIsolatedWorldSecurityOrigin have been deprecated in favor of webFrame.setIsolatedWorldInfo.

Mixed sandbox​

enableMixedSandbox and the --enable-mixed-sandbox command-line switch still exist for compatibility, but are deprecated and have no effect.

End of support for 2.0.x​

Per our supported versions policy, 2.0.x has reached end of life.

Программа отзывов​

We continue to use our App Feedback Program for testing. Projects who participate in this program test Electron betas on their apps; and in return, the new bugs they find are prioritized for the stable release. If you'd like to participate or learn more, check out our blog post about the program.

Что дальше​

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. Although we are careful not to make promises about release dates, our plan is release new major versions of Electron with new versions of those components approximately quarterly. The tentative 6.0.0 schedule maps out key dates in the Electron 6 development life cycle. Also, see our versioning document for more detailed information about versioning in Electron.

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

How do Electron's features written in C++ or Objective-C get to JavaScript so they're available to an end-user?

Background​

Electron is a JavaScript platform whose primary purpose is to lower the barrier to entry for developers to build robust desktop apps without worrying about platform-specific implementations. However, at its core, Electron itself still needs platform-specific functionality to be written in a given system language.

In reality, Electron handles the native code for you so that you can focus on a single JavaScript API.

How does that work, though? How do Electron's features written in C++ or Objective-C get to JavaScript so they're available to an end-user?

To trace this pathway, let's start with the app module.

By opening the app.ts file inside our lib/ directory, you'll find the following line of code towards the top:

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

This line points directly to Electron's mechanism for binding its C++/Objective-C modules to JavaScript for use by developers. This function is created by the header and implementation file for the ElectronBindings class.

process.electronBinding​

These files add the process.electronBinding function, which behaves like Node.js’ process.binding. process.binding is a lower-level implementation of Node.js' require() method, except it allows users to require native code instead of other code written in JS. This custom process.electronBinding function confers the ability to load native code from Electron.

When a top-level JavaScript module (like app) requires this native code, how is the state of that native code determined and set? Where are the methods exposed up to JavaScript? What about the properties?

native_mate​

At present, answers to this question can be found in native_mate: a fork of Chromium's gin library that makes it easier to marshal types between C++ and JavaScript.

Inside native_mate/native_mate there's a header and implementation file for object_template_builder. This is what allow us to form modules in native code whose shape conforms to what JavaScript developers would expect.

mate::ObjectTemplateBuilder​

If we look at every Electron module as an object, it becomes easier to see why we would want to use object_template_builder to construct them. This class is built on top of a class exposed by V8, which is Google’s open source high-performance JavaScript and WebAssembly engine, written in C++. V8 implements the JavaScript (ECMAScript) specification, so its native functionality implementations can be directly correlated to implementations in JavaScript. For example, v8::ObjectTemplate gives us JavaScript objects without a dedicated constructor function and prototype. It uses Object[.prototype], and in JavaScript would be equivalent to Object.create().

To see this in action, look to the implementation file for the app module, atom_api_app.cc. At the bottom is the following:

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

In the above line, .SetMethod is called on mate::ObjectTemplateBuilder. .SetMethod can be called on any instance of the ObjectTemplateBuilder class to set methods on the Object prototype in JavaScript, with the following syntax:

.SetMethod("method_name", &function_to_bind)

This is the JavaScript equivalent of:

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

This class also contains functions to set properties on a module:

.SetProperty("property_name", &getter_function_to_bind)

или

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

These would in turn be the JavaScript implementations of Object.defineProperty:

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

и

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

It’s possible to create JavaScript objects formed with prototypes and properties as developers expect them, and more clearly reason about functions and properties implemented at this lower system level!

The decision around where to implement any given module method is itself a complex and oft-nondeterministic one, which we'll cover in a future post.

As Electron grows in popularity for desktop applications, the team working on it has also grown: we have more fulltime maintainers who work for different companies, live in different timezones, and have different interests. We're introducing a governance structure so we can keep growing smoothly.

Why are things changing?​

People in the Electron project coordinate in timezones around the world with volunteers, with full-time maintainers, and with several companies who all rely on Electron. Until now, we've been successful with informal coordination; but as the team has grown, we've found that the approach doesn't scale. We also want to make it easier for new contributors to find a place to call home in the project.

Рабочие группы​

Electron governance includes working groups that are responsible for different parts of the project. We're starting out with seven groups:

• Community & Safety: Handles Code of Conduct issues.
• Docs & Tooling: Oversees externally-focused tooling (e.g. Fiddle, Forge) and the Electron documentation.
• Outreach: Helps grow the Electron community.
• Releases: Ensures releases are stable and on schedule.
• Security: Performs security testing and responds to security issues.
• Upgrades: Integrates upstream upgrades, such as new versions of V8, Chromium, and Node.
• Website: Maintains and improves the Electron website.

These groups will coordinate with each other, but each has their own meeting schedules and agendas to be productive on their own. More details on these groups are available at the governance repository.

Does this change the Electron project's direction?​

This shouldn't have any direct effect on Electron's direction. If our strategy is successful, working groups will make it easier for new contributors to find topics that interest them, and make maintainers' lives simpler by moving discussion unrelated to their day-to-day work to other groups. If that happens, it may indirectly affect things by having more unblocked people working together.

Where can I learn more?​

• The governance repo and charter have information about the new governance structure.
• Each working group has its own page: Community, Docs & Tools, Outreach, Releases, Security, Upgrades, and Website.
• You can contact the maintainers by opening an issue or mailing us at info@electronjs.org.

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

This vulnerability has been assigned 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.

Scope​

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:

• 4.0.8
• 3.1.6
• 3.0.16
• 2.0.18

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

• 5.0.0-beta.5

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.

Команда Electron прекратит поддержку 32-разрядных Linux (ia32 / i386), начиная с Electron v4.0. Последней версией Electron, поддерживающей 32-битные установки Linux, является Electron v3.1, которая будет получать поддержку до выхода Electron v6. Поддержка для 64-разрядного Linux и armv7l останется неизменной.

Что именно Electron больше не поддерживает?​

Вы возможно видели "64-bit" и "32-bit" в виде наклеек на вашем ПК или вариантов при скачивании ПО. Термин используется, чтобы указать конкретную архитектуру компьютера. Большинство компьютеров, выпущенных в 1990ых и ранних 2000ых, используют процессор, основанный на 32-разрядной архитектуре, пока большинство компьютеров, выпущенных позже, основаны на более новой и мощной 64-разрядной архитектуре. Nintendo 64 (выкупили?) и Playstation 2 были первыми широко доступными потребительскими устройствами с новой архитектурой, компьютеры, продаваемые после 2010, в основном имели исключительно 64-разрядные процессоры. Как результат, поддержка была сокращена: Google перестал выпускать Chrome для 32-разрядного Linux с мая 2016, Canonical перестали предоставлять 32-разрядные образы в 2017 и прекратили поддержку 32-разрядных систем с выходом Ubuntu 18.10. Arch Linux, elementary OS и прочие известные Linux дистрибутивы уже прекратили поддержку устаревшей архитектуры.

До сего момента, Electron предоставлял и поддерживал сборки, которые работают на старой 32-разрядной архитектуре. С релизом версии 4.0, команда Electron больше не будет предоставлять бинарные файлы или поддержку для 32-разрядного Linux.

Electron всегда был активным open-source проектом, так что мы продолжим поддерживать и поощрять разработчиков, заинтересованных в сборке Electron для экзотических архитектур.

Что это значит для разработчиков?​

Если вы не предоставляете 32-разрядные версии вашего приложения для Linux, то ничего не изменится.

Проекты, которые предоставляют 32-разрядные приложения на Electron для Linux, должны определиться, как их продолжить. 32-разрядный Linux будет поддерживаться на Electron 3 до выхода Electron 6, что дает некоторое время для принятия решений и планов.

Что это значит для пользователей?​

Если вы пользователь Linux и не уверены в том, что используете 64-разрядную систему, скорее всего вы работаете на 64-разрядной архитектуре. Чтобы убедиться в этом, вы можете выполнить команды lscpu или uname -m в вашем терминале. Одна из них выдаст вашу текущую архитектуру.

Если вы используете Linux на 32-разрядном процессоре, скорее всего вы уже столкнулись с трудностями при поиске актуального ПО для вашей операционной системы. Команда Electron присоединяется к другим авторитетным членам сообщества Linux, рекомендовав вам перейти на 64-разрядную архитектуру.

A code vulnerability has been discovered that allows Node to be re-enabled in child windows.

Opening a BrowserView with sandbox: true or nativeWindowOpen: true and nodeIntegration: false results in a webContents where window.open can be called and the newly opened child window will have nodeIntegration enabled. This vulnerability affects all supported versions of 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. We encourage all Electron developers to update their apps to the latest stable version immediately.

If for some reason you are unable to upgrade your Electron version, you can mitigate this issue by disabling all child web contents:

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

Further Information​

This vulnerability was found and reported responsibly to the Electron project by PalmerAL.

Чтобы узнать больше о лучших методах обеспечения безопасности приложений Electron, смотрите наш учебник по безопасности.

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