El equipo de Electron esta emocionado de anunciar el lanzamiento de Electron 5.0.0! Puedes instalarlo con npm a través de npm install electron@latest o descargar los archivos tar desde nuestra página de lanzamientos. La versión está empaquetada con versiones nuevas, correcciones y características nuevas. ¡No podemos esperar a ver lo que construyes con ellos! ¡Sigue leyendo para obtener más detalles sobre esta versión, y por favor comparte tus comentarios!

¿Qué es lo nuevo?​

Gran parte de la funcionalidad de Electron es proporcionada por los componentes principales de Chromium, Node.js y V8. Electron se mantiene actualizado con estos proyectos para proporcionar a nuestros usuarios características nuevas de JavaScript, mejoras de rendimiento y correcciones de seguridad. Cada uno de estos paquetes tiene una versión mayor en Electron 5:

• Chromium 73.0.3683.119
  • Nuevo en 70
  • Nuevo en 71
  • Nuevo en 72
  • Nuevo en 73
• Node.js 12.0.0
  • Nodo 12 de Blog Publicado
• V8 7.3.492.27.
  • Característica JS nueva

Electron 5 también incluye mejoras en APIs específicas de Electron. Un resumen de los cambios principales está a continuación; para la lista completa de cambios, revisa las notas de lanzamiento de Electrón v5.0.0.

Promisificación​

Electron 5 continúa Iniciativa de Promisificación para convertir la API basada en la devolución de invocaciones de Electron para usar Promises. Estas API fueron convertidas para Electron 5:

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

Acceso a colores del sistema para macOS​

Estas funciones fueron cambiadas o añadidas a systemPreferences para acceder a los colores de los sistemas macOS:

• sistema.getAccentColor
• systemPreferences.getColor
• systemPreferences.getSystem Color

Información de la memoria del proceso​

La función process.getProcessMemoryInfo ha sido añadida para obtener estadísticas de uso de memoria sobre el proceso actual.

Filtrado adicional para API remotas​

Para mejorar la seguridad en la API remote, se han añadido nuevos eventos remotos para que remote.getBuiltin, remote.getCurrentWindow, remote.getCurrentWebContents y <webview>.getWebContents pueden ser filtrados.

Múltiples vistas de navegador en la ventana de navegador​

BrowserWindow ahora soporta la administración de múltiples BrowserViews dentro del mismo BrowserWindow.

Restaurar archivos borrados​

Por defecto para aplicaciones empaquetadas​

Las aplicaciones empaquetadas ahora se comportarán como la aplicación predeterminada: se creará un menú de aplicación predeterminado a menos que la aplicación tenga una y el evento window-all-closed se gestionará automáticamente a menos que la aplicación gestione el evento.

Arenero Mixto​

El modo Arenero-mixto ahora está habilitado por defecto. Los renderizadores lanzados con sandbox: true ahora serán realmente hecho el arenero, donde previamente solo estarían enrollados si el modo mixed-sandbox también estaba activado.

Mejoras en seguridad​

Los valores por defecto de nodeIntegration y webviewTag ahora son false para mejorar la seguridad.

Comprobante ortográfico ahora asíncrono​

La API SpellCheck ha sido cambiada para proveer resultados asíncronos.

Obsolescencia​

Las siguientes API están recientemente obsoletas en Electron 5.0.0 y están planificadas para su retirada en 6.0.0:

Binarios de instantánea Mksnapshot para arm y arm64​

Los binarios nativos de mksnapshot para brazo y arm64 están obsoletos y se eliminarán en 6. .0. Se pueden crear instantáneas para brazos y arm64 usando los binarios x64.

API de ServiceWorker en WebContents​

Las API de ServiceWorker Deprecated en WebContents para preparar su retirada.

• webContents.hasServiceWorker
• webContents.unregisterServiceWorker

Módulos automáticos con contenido de webContents en arenero​

Para mejorar la seguridad. los siguientes módulos están siendo obsoletos para su uso directamente a través de requerir y en su lugar necesitarán ser incluidos a través de remote.require en un arenero de contenido web:

• electron.screen
• child_process
• fs
• os
• ruta

webFrame APIs del mundo Aislado​

webFrame.setIsolatedWorldContentSecurityPolicy,webFrame.setIsolatedWorldHumanReadableName, webFrame.setIsolatedWorldSecurityOrigin han sido obsoletos a favor de webFrame.setIsolatedWorldInfo.

Arenero Mixto​

enableMixedSandbox y el interruptor de línea de comandos --enable-mixed-sandbox siguen existiendo por compatibilidad, pero están obsoletos y no tienen efecto.

Fin de mantenimiento para 2.0.x​

Por nuestra directiva de versiones admitidas, 2.0.x ha llegado al fin de su vida.

Programa de retroalimentación​

Continuamos usando nuestro Programa de Comentarios de para pruebas. Los proyectos quienes participan en este programa de pruebas de las betas de Electron en sus aplicaciones; y a cambio, los defectos nuevos que encuentran están priorizados para la versión estable. Si quieres participar o aprender más, revisa nuestra publicación de nuestro blog sobre el programa.

¿Y ahora, qué?​

A corto plazo puedes esperar que el equipo continúe enfocándose en mantener al día con el desarrollo de los principales componentes que componen Electron, incluyendo Chromium, Node, y V8. Aunque tenemos cuidado de no hacer promesas sobre las fechas de lanzamiento, nuestro plan es lanzar versiones nuevas importantes de Electron con versiones nuevas de esos componentes aproximadamente cada trimestre. El calendario tentativo 6.0.0 traza fechas claves en el ciclo de vida del desarrollo de Electron 6. Además, consulta nuestro documento de versionado para obtener información más detallada sobre el versionado en Electron.

Para obtener información sobre los cambios de ruptura previstos en las próximas versiones de Electron, consulte nuestro documento de Cambios Planificados de Ruptura.

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

Fondo​

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. Desbloqueo.ElectronBindings``ElectronBindings

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.

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)

o

.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
  }
})

y

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.

Grupos de trabajo​

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.

Ámbito​

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

Mitigación​

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

Más información​

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.

Para aprender más sobre las buenas prácticas para mantener tus aplicaciones Electron seguras, ve nuestro tutorial de seguridad.

Please file a GitHub Security Advisory if you wish to report a vulnerability in Electron.

El equipo de Electron suspenderá el soporte para Linux de 32 bits (ia32 / i386) a partir de Electron v4.0. La última versión de Electron que soporta instalaciones basadas en 32 bits de Linux es Electron v3.1, que recibirá versiones de soporte hasta que Electron v6 sea liberado. 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.

What does that mean for developers?​

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.

What does that mean for users?​

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.

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.

Mitigación​

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());

Más información​

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

Para aprender más sobre las buenas prácticas para mantener tus aplicaciones Electron seguras, ve nuestro tutorial de seguridad.

Please file a GitHub Security Advisory if you wish to report a vulnerability in Electron.

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.

Ayuda! 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.

Por primera vez en la historia, Electron está emocionado de dar a conocer nuestro programa de lanzamiento a partir de la v5. Este es nuestro primer paso para tener una cronología pública a largo plazo.

Como se menciona en nuestra versión estable v 4.0.0 publicación de blog, estamos planeando lanzarla aproximadamente trimestralmente para Mantén una cadencia más cercana con los lanzamientos de Chromium. Chromium publica una versión nueva muy rápidamente -- cada 6 semanas.

Echa un vistazo a la progresión en Electron versus Chromium lado a lado:

En la última mitad de 2018, nuestra principal prioridad era liberar más rápido y acercarnos a Chromium. Lo conseguimos aferrándonos a una línea temporal predeterminada. Electron 3.0.0 y 4.0.0 fueron liberados en una línea temporal de 2-3 meses para cada lanzamiento. Somos optimistas en cuanto a continuar con ese ritmo en la liberación de 5.0.0 y más adelante. Con un importante lanzamiento de Electron aproximadamente cada cuartero, ahora estamos a la par con la cadencia de lanzamiento de Chromium. Lograr la liberación estable de Chromium es siempre un objetivo para nosotros y estamos dando pasos para lograrlo.

Nos encantaría prometer fechas futuras como Nodo.js y Chromium lo hacen, pero no estamos en ese lugar aún. Somos optimistas en cuanto a que alcanzaremos cronología a un plazo largo en el futuro.

Con esto en mente, estamos dando los primeros pasos publicando nuestro calendario de lanzamiento para v5.0.0. Puedes encontrar eso aquí.

Para ayudarnos a probar nuestras versiones beta y estabilización, por favor considera unirte a nuestro Programa de Comentarios de App.

¡ El equipo de electrones se complace en anunciar que el lanzamiento estable de Electron 4 ya está disponible! Puedes instalarlo desde electronjs.org o desde npm a través de npm install electron@latest. El lanzamiento está repleto de actualizaciones, correcciones y nuevas características, y no podemos esperar a ver lo que construyes con ellos. ¡Lea más para obtener más información sobre esta versión, y por favor comparta cualquier comentario que tenga mientras explora!

¿Qué es lo nuevo?​

Una gran parte de la funcionalidad de Electron es proporcionada por Chromium, Node.js y V8, los componentes principales que componen Electron. Como tal, un objetivo clave para el equipo de Electron es mantenerse al día con los cambios en estos proyectos tanto como sea posible proporcionando a los desarrolladores que construyen aplicaciones Electron acceso a nuevas características web y JavaScript. Con este fin, Electron 4 presenta los principales saltos de versión de cada uno de estos componentes; Electron v 4.0.0 incluye 69.0.3497.106de cromo, 10.11.0de nodo y 6.9.427.24V8.

Además, Electron 4 incluye cambios en las APIs específicas de Electron. Puedes encontrar un resumen de los cambios principales en Electron 4 a continuación; para ver la lista completa de cambios, revisa las notas de lanzamiento de Electron v 4.0.0.

Deshabilitar el módulo remote​

Ahora tiene la habilidad de desactivar el módulo remote por razones de seguridad. El módulo puede ser deshabilitado para etiquetas BrowserWindows y webview:

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

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

Consulte la documentación de BrowserWindow y <webview> Tag para más información.

Filtrando remote.require() / remote.getGlobal() solicitudes​

Esta característica es útil si no desea deshabilitar completamente el módulo remote en su proceso de renderizado o webview pero le gustaría un control adicional sobre qué módulos pueden ser requeridos vía remote.require.

Cuando se requiere un módulo a través de remote.require en un proceso de renderizado, se eleva un evento remote-require en el módulo app. Puede llamar a event.preventDefault() en el evento (el primer argumento) para evitar que el módulo sea cargado. La WebContents instancia donde ocurrió la solicitud es pasada como el segundo argumento, y el nombre del módulo es pasado como el tercer argumento. El mismo evento también se emite en la instancia de WebContents, pero en este caso, los únicos argumentos son el evento y el nombre del módulo. En ambos casos, puede devolver un valor personalizado estableciendo el valor de event.returnValue.

// Controla `remote.require` desde todos los 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) {
    // ...
  },
);

De una manera similar, cuando se llama a remote.getGlobal(name), se levanta un evento remote-get-global. Esto funciona del mismo modo que el evento remote-require: llame a preventDefault() para evitar que el global sea devuelto, y establece event.returnValue para retornar un valor personalizado.

// 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) {
    // ...
  },
);

Para obtener más información, consulte la siguiente documentación:

• remote.require
• remote.getGlobal
• app
• WebContents

JavaScript Access to the About Panel​

En macOS, ahora puede llamar a app.showAboutPanel() para mostrar programáticamente el panel Acerca, al igual que hacer clic en el elemento de menú creado a través de {role: 'about'}. Vea la documentación de showAboutPanel para más información

Controlando WebContents Limitando el segundo plano​

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.setBackgroundThrottling(enableBackgroundThrottling)
win.webContents.setBackgroundThrottling(enableBackgroundThrottling)

See the setBackgroundThrottling documentation for more information.

Restaurar archivos borrados​

No más soporte para macOS 10.9​

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.

Obsolescencia​

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:

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.

Programa de retroalimentación​

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.

¿Y ahora, qué?​

A corto plazo puedes esperar que el equipo continúe enfocándose en mantener al día con el desarrollo de los principales componentes que componen Electron, incluyendo Chromium, Node, y V8. Aunque tenemos cuidado de no hacer promesas sobre las fechas de lanzamiento, nuestro plan es lanzar versiones nuevas importantes de Electron con versiones nuevas de esos componentes aproximadamente cada trimestre. See our versioning document for more detailed information about versioning in Electron.

Para obtener información sobre los cambios de ruptura previstos en las próximas versiones de Electron, consulte nuestro documento de Cambios Planificados de Ruptura.

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

Ámbito​

Electron applications using Web SQL are impacted.

Mitigación​

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:

• 4.0.0-beta.11
• 3.1.0-beta.4
• 3.0.13
• 2.0.16

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

Más información​

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

Para aprender más sobre las buenas prácticas para mantener tus aplicaciones Electron seguras, ve nuestro tutorial de seguridad.

Please file a GitHub Security Advisory if you wish to report a vulnerability in Electron.