¡Electron 30.0.0 ha sido liberado! It includes upgrades to Chromium 124.0.6367.49, V8 12.4, and Node.js 20.11.1.

El equipo de Electron esta emocionado de anunciar el lanzamiento de Electron 30.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release.

If you have any feedback, please share it with us on Twitter or Mastodon, or join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

Notable Changes​

Highlights​

• ASAR Integrity fuse now supported on Windows (#40504)
  • Existing apps with ASAR Integrity enabled may not work on Windows if not configured correctly. Apps using Electron packaging tools should upgrade to @electron/packager@18.3.1 or @electron/forge@7.4.0.
  • Take a look at our ASAR Integrity tutorial for more information.
• Added WebContentsView and BaseWindow main process modules, deprecating & replacing BrowserView (#35658)
  • BrowserView is now a shim over WebContentsView and the old implementation has been removed.
  • See our Web Embeds documentation for a comparison of the new WebContentsView API to other similar APIs.
• Implemented support for the File System API (#41827)

Stack Changes​

• Chromium 124.0.6367.49
  • New in Chrome 124 and in DevTools 124
  • New in Chrome 123 and in DevTools 123
• Node 20.11.1
  • Node 20.11.1 notes
• V8 12.4

Electron 30 upgrades Chromium from 122.0.6261.39 to 124.0.6367.49, Node from 20.9.0 to 20.11.1, and V8 from 12.2 to 12.4.

Nuevas características​

• Added a transparent webpreference to webviews. (#40301)
• Added a new instance property navigationHistory on webContents API with navigationHistory.getEntryAtIndex method, enabling applications to retrieve the URL and title of any navigation entry within the browsing history. (#41662)
• Added new BrowserWindow.isOccluded() method to allow apps to check occlusion status. (#38982)
• Added proxy configuring support for requests made with the net module from the utility process. (#41417)
• Added support for Bluetooth ports being requested by service class ID in navigator.serial. (#41734)
• Added support for the Node.js NODE_EXTRA_CA_CERTS CLI flag. (#41822)

Restaurar archivos borrados​

Behavior Changed: cross-origin iframes now use Permission Policy to access features​

Cross-origin iframes must now specify features available to a given iframe via the allow attribute in order to access them.

See documentation for more information.

Removed: The --disable-color-correct-rendering command line switch​

This switch was never formally documented but its removal is being noted here regardless. Chromium itself now has better support for color spaces so this flag should not be needed.

Behavior Changed: BrowserView.setAutoResize behavior on macOS​

In Electron 30, BrowserView is now a wrapper around the new WebContentsView API.

Previously, the setAutoResize function of the BrowserView API was backed by autoresizing on macOS, and by a custom algorithm on Windows and Linux. For simple use cases such as making a BrowserView fill the entire window, the behavior of these two approaches was identical. However, in more advanced cases, BrowserViews would be autoresized differently on macOS than they would be on other platforms, as the custom resizing algorithm for Windows and Linux did not perfectly match the behavior of macOS's autoresizing API. The autoresizing behavior is now standardized across all platforms.

If your app uses BrowserView.setAutoResize to do anything more complex than making a BrowserView fill the entire window, it's likely you already had custom logic in place to handle this difference in behavior on macOS. If so, that logic will no longer be needed in Electron 30 as autoresizing behavior is consistent.

Removed: params.inputFormType property on context-menu on WebContents​

The inputFormType property of the params object in the context-menu event from WebContents has been removed. Use the new formControlType property instead.

Removed: process.getIOCounters()​

Chromium has removed access to this information.

Fin de soporte para 27.x.y​

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

What's Next​

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.

You can find Electron's public timeline here.

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

¡Estamos encantados de anunciar que Electron ha sido aceptado como una organización mentora para la vigésima edición de Google Summer of Code (GSoC) 2024! Google Summer of Code es un programa global centrado en traer nuevos colaboradores al desarrollo de software de código abierto.

Para obtener más detalles del programa, consulta la página de inicio de Summer of Code.

Sobre nosotros​

Electron es un framework JavaScript para construir aplicaciones multiplataforma de escritorio usando tecnologías web. El framework central de Electron es un ejecutable binario compilado construido con Chromium y Node.js, y está escrito principalmente en C++.

Fuera del núcleo de Electron, también trabajamos en una variedad de proyectos para ayudar a sostener la organización de Electron como:

• Herramientas de distribución del usuario final (por ejemplo, Electron Forge y update.electronjs.org).
• Material de aprendizaje para desarrolladores de Electron (por ejemplo, electronjs.org y Electron Fiddle).
• Herramientas internas para optimizar la productividad del desarrollador (por ejemplo, Electron Build Tools y Sheriff).

Como colaborador de Summer of Code, estarías colaborando con algunos de los principales colaboradores de Electron en uno de los muchos proyectos bajo el paraguas github.com/electron.

Antes de aplicar​

Si no estás muy familiarizado con Electron, te recomendamos que comiences leyendo la documentación y probando ejemplos en Electron Fiddle.

Para obtener más información sobre la distribución de aplicaciones Electron también puede jugar con Electron Forge creando una aplicación de muestra:

npm init electron-app@latest my-app

Después de familiarizarte un poco con el código, ven a unirte a la conversación en el Servidor de Discord de Electron.

Elaborando su propuesta​

¿Estás interesado en colaborar con Electron? Primero, revisa los siete borradores de ideas del proyecto que hemos preparado. Todas las ideas de la lista están actualmente abiertas a propuestas.

¿Tienes una idea diferente que te gustaría tener en cuenta? También estamos abiertos a aceptar nuevas ideas que no están en la lista de proyectos propuestos. pero asegúrese de que su enfoque está completamente esbozado y detallado. En caso de duda, le recomendamos que se aferre a nuestras ideas listadas.

Su solicitud debe incluir:

• Tu propuesta: un documento escrito que describe en detalle lo que planeas lograr durante el curso del verano.
• Su experiencia como desarrollador. Si tiene un currículum, por favor incluya una copia. De lo contrario, cuéntanos tu experiencia técnica pasada.
  • La falta de experiencia en ciertas áreas no te descalificará, pero ayudará a nuestros mentores a elaborar un plan para ayudarte mejor y asegurarte de que tu proyecto de verano sea un éxito.

[Aquí está una guía detallada de qué enviar como parte de tu aplicación Electron.](https://electronhq.notion. ite/Electron-GSoC-2024-Contributor-Guidance-f1f4de7a0d9a4664a96c8d4dd70cb208?pvs=4) Enviar propuestas directamente al portal de Google Summer of Code. Tenga en cuenta que las propuestas enviadas por correo electrónico al equipo Electron en lugar de enviarlas a través del portal de la aplicación no serán consideradas como un envío final.

Si desea más orientación sobre su propuesta o no está seguro de qué incluir, también recomendamos que sigas [la propuesta oficial de Google Summer of Code escribiendo consejos aquí](https://google. ithub.io/gsocguides/student/writing-a-proposal).

Aplicaciones abiertas el 18 de marzo de 2024 y cierran el 2 de abril de 2024.

¿Preguntas?​

Si tienes preguntas que no enviamos en las publicaciones del blog o consultas para tu borrador de propuestas, por favor envíanos un correo electrónico a Summer-of-code@electronjs. rg o revisa GSoC FAQ!

Recursos​

• Electron Google Summer of Code 2024 Lista de ideas
• Electron Google Summer of Code 2024 Orientación para contribuyentes
• Guía para estudiantes/colaboradores de Google Summer of Code

¡Electron 29.0.0 ha sido liberado! It includes upgrades to Chromium 122.0.6261.39, V8 12.2, and Node.js 20.9.0.

El equipo de Electron esta emocionado de anunciar el lanzamiento de Electron 29.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release.

If you have any feedback, please share it with us on Twitter or Mastodon, or join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

Notable Changes​

Highlights​

• Added a new top-level webUtils module, a renderer process module that provides a utility layer to interact with Web API objects. The first available API in the module is webUtils.getPathForFile. Electron's previous File.path augmentation was a deviation from web standards; this new API is more in line with current web standards behavior.

Stack Changes​

• Chromium 122.0.6261.39
  • New in Chrome 122 and in DevTools 122
  • New in Chrome 121 and in DevTools 121
• Node 20.9.0
  • Node 20.9.0 notes
  • Node 20.0.0 notes
• V8 12.2

Electron 29 upgrades Chromium from 120.0.6099.56 to 122.0.6261.39, Node from 18.18.2 to 20.9.0, and V8 from 12.0 to 12.2.

Nuevas características​

• Added new webUtils module, a utility layer to interact with Web API objects, to replace File.path augmentation. #38776
• Added net module to utility process. #40890
• Added a new Electron Fuse, grantFileProtocolExtraPrivileges, that opts the file:// protocol into more secure and restrictive behaviour that matches Chromium. #40372
• Added an option in protocol.registerSchemesAsPrivileged to allow V8 code cache in custom schemes. #40544
• Migrated app.{set|get}LoginItemSettings(settings) to use Apple's new recommended underlying framework on macOS 13.0+. #37244

Restaurar archivos borrados​

Behavior Changed: ipcRenderer can no longer be sent over the contextBridge​

Attempting to send the entire ipcRenderer module as an object over the contextBridge will now result in an empty object on the receiving side of the bridge. This change was made to remove / mitigate a security footgun. You should not directly expose ipcRenderer or its methods over the bridge. Instead, provide a safe wrapper like below:

contextBridge.exposeInMainWorld('app', {
  onEvent: (cb) => ipcRenderer.on('foo', (e, ...args) => cb(args)),
});

Removed: renderer-process-crashed event on app​

The renderer-process-crashed event on app has been removed. Use the new render-process-gone event instead.

// Removed
app.on('renderer-process-crashed', (event, webContents, killed) => {
  /* ... */
});

// Replace with
app.on('render-process-gone', (event, webContents, details) => {
  /* ... */
});

Removed: crashed event on WebContents and <webview>​

The crashed events on WebContents and <webview> have been removed. Use the new render-process-gone event instead.

// Removed
win.webContents.on('crashed', (event, killed) => {
  /* ... */
});
webview.addEventListener('crashed', (event) => {
  /* ... */
});

// Replace with
win.webContents.on('render-process-gone', (event, details) => {
  /* ... */
});
webview.addEventListener('render-process-gone', (event) => {
  /* ... */
});

Removed: gpu-process-crashed event on app​

The gpu-process-crashed event on app has been removed. Use the new child-process-gone event instead.

// Removed
app.on('gpu-process-crashed', (event, killed) => {
  /* ... */
});

// Replace with
app.on('child-process-gone', (event, details) => {
  /* ... */
});

Fin de soporte para 26.x.y​

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

What's Next​

Did you know that Electron recently added a community Request for Comments (RFC) process? If you want to add a feature to the framework, RFCs can be a useful tool to start a dialogue with maintainers on its design. You can also see upcoming changes being discussed in the Pull Requests. To learn more, check out our Introducing electron/rfcs blog post, or check out the README of the electron/rfcs repository directly.

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.

You can find Electron's public timeline here.

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

Electron’s API Working Group is adopting an open Requests for Comments (RFC) process to help shepherd larger changes to Electron core.

Why RFCs?​

In short, we want to smooth out the process of landing significant changes to Electron core.

Currently, new code changes are mostly discussed through issues and pull requests on GitHub. For most changes to Electron, this is a good system. Many bug fixes, documentation changes, and even new features are straightforward enough to review and merge asynchronously through standard GitHub flows.

For changes that are more significant—for instance, large API surfaces or breaking changes that would affect the majority of Electron apps—it makes sense for review to happen at the ideation stage before most of the code is written.

This process is designed to be open to the public, which will also make it easier for the open source community at large to give feedback on potential changes before they land in Electron.

¿Cómo funciona?​

The entire RFC process lives in the electron/rfcs repository on GitHub. The steps are described in detail in the repository README.

In brief, an RFC is Proposed once a PR is made to the electron/rfcs repository. A Proposed RFC becomes:

• Active when the PR is merged into the main branch of the repository, which means that Electron maintainers are amenable to an implementation in electron/electron, or
• Declined if the PR is ultimately rejected.

An Active RFC is Completed if the implementation has been merged into electron/electron.

Who can participate?​

Anyone in the Electron community can submit RFCs or leave feedback on the electron/rfcs repository!

• To see the list of active RFCs, refer to the text folder in the repository.
• To leave feedback on proposed RFCs, check out the list of open PRs.
• To submit a new RFC, check out the repo’s README and the RFC template.

We wanted to make this process a two-way dialogue and encourage community participation to get a diverse set of opinions from Electron apps that might consume these APIs in the future. If you’re interested in leaving feedback on currently proposed RFCs, the Electron maintainers have already created a few:

• Electron C APIs
• Preload Realm for Service Workers

Credits​

Electron's RFC process was modeled on many established open source RFC processes. Inspiration for many ideas and major portions of copywriting go to:

• emberjs/rfcs
• reactjs/rfcs
• rust-lang/rfcs
• tauri-apps/rfcs
• vuejs/rfcs
• yarnpkg/rfcs

Hoy temprano, el equipo de Electron fue alertado sobre varios CVEs públicos presentados recientemente contra varias aplicaciones notables de Electron. Los CVEs están relacionados a dos fuses de Electron - runAsNode y enableNodeCliInspectArguments - y afirman incorrectamente que un atacante remoto puede ser capaz de ejecutar código arbitrario a través de estos componentes si no han sido desactivados activamente.

No creemos que estos CVE se presentaran de buena fe. En primer lugar, la afirmación es incorrecta - la configuración no habilita la ejecución remota de código. En segundo lugar, las empresas citadas en estos CVE no han sido notificadas a pesar de tener programas de recompensas por errores. Por último, si bien creemos que desactivar los componentes en cuestión mejora la seguridad de la aplicación, no creemos que los CVE se hayan calificado con la gravedad correcta. “Critical” is reserved for issues of the highest danger, which is certainly not the case here.

Anyone is able to request a CVE. While this is good for the overall health of the software industry, “farming CVEs” to bolster the reputation of a single security researcher is not helpful.

That said, we understand that the mere existence of a CVE with the scary critical severity might lead to end user confusion, so as a project, we’d like to offer guidance and assistance in dealing with the issue.

How might this impact me?​

After reviewing the CVEs, the Electron team believes that these CVEs are not critical.

An attacker needs to already be able to execute arbitrary commands on the machine, either by having physical access to the hardware or by having achieved full remote code execution. This bears repeating: The vulnerability described requires an attacker to already have access to the attacked system.

Chrome, for example, does not consider physically-local attacks in their threat model:

We consider these attacks outside Chrome's threat model, because there is no way for Chrome (or any application) to defend against a malicious user who has managed to log into your device as you, or who can run software with the privileges of your operating system user account. Such an attacker can modify executables and DLLs, change environment variables like PATH, change configuration files, read any data your user account owns, email it to themselves, and so on. Such an attacker has total control over your device, and nothing Chrome can do would provide a serious guarantee of defense. This problem is not special to Chrome ­— all applications must trust the physically-local user.

The exploit described in the CVEs allows an attacker to then use the impacted app as a generic Node.js process with inherited TCC permissions. So if the app, for example, has been granted access to the address book, the attacker can run the app as Node.js and execute arbitrary code which will inherit that address book access. This is commonly known as a “living off the land” attack. Attackers usually use PowerShell, Bash, or similar tools to run arbitrary code.

Am I impacted?​

By default, all released versions of Electron have the runAsNode and enableNodeCliInspectArguments features enabled. If you have not turned them off as described in the Electron Fuses documentation, your app is equally vulnerable to being used as a “living off the land” attack. Again, we need to stress that an attacker needs to already be able to execute code and programs on the victim’s machine.

Mitigación​

The easiest way to mitigate this issue is to disable the runAsNode fuse within your Electron app. The runAsNode fuse toggles whether the ELECTRON_RUN_AS_NODE environment variable is respected or not. Please see the Electron Fuses documentation for information on how to toggle theses fuses.

Please note that if this fuse is disabled, then process.fork in the main process will not function as expected as it depends on this environment variable to function. En su lugar, le recomendamos que use Utility Processes, el cual funciona para muchos casos de usos donde se necesita un proceso independiente de Node.js (como un proceso de un servidor Sqlite o escenarios similares).

You can find more info about security best practices we recommend for Electron apps in our Security Checklist.

¡Electron 28.0.0 ha sido liberado! It includes upgrades to Chromium 120.0.6099.56, V8 12.0, and Node.js 18.18.2.

El equipo de Electron esta emocionado de anunciar el lanzamiento de Electron 28.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release.

If you have any feedback, please share it with us on Twitter or Mastodon, or join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

Notable Changes​

Highlights​

• Implemented support for ECMAScript modules or ESM (What are ECMAScript modules? learn more here. This includes support for ESM in Electron proper, as well as areas such as the UtilityProcess API entrypoints. See our ESM documentation for more details.
• In addition to enabling ESM support in Electron itself, Electron Forge also supports using ESM to package, build and develop Electron applications. You can find this support in Forge v7.0.0 or higher.

Stack Changes​

• Chromium 120.0.6099.56
  • New in Chrome 119 and in DevTools 119
  • New in Chrome 120 and in DevTools 120
• Node 18.18.2
  • Node 18.18.0 notes
  • Node 18.18.1 notes
  • Node 18.18.2 notes
• V8 12.0

Nuevas características​

• Enabled ESM support. #37535
  • For more details, see the ESM documentation.
• Added ESM entrypoints to the UtilityProcess API. #40047
• Added several properties to the display object including detected, maximumCursorSize, and nativeOrigin. #40554
• Added support for ELECTRON_OZONE_PLATFORM_HINT environment variable on Linux. #39792

Restaurar archivos borrados​

Behavior Changed: WebContents.backgroundThrottling set to false affects all WebContents in the host BrowserWindow​

WebContents.backgroundThrottling set to false will disable frames throttling in the BrowserWindow for all WebContents displayed by it.

Removed: BrowserWindow.setTrafficLightPosition(position)​

BrowserWindow.setTrafficLightPosition(position) has been removed, the BrowserWindow.setWindowButtonPosition(position) API should be used instead which accepts null instead of { x: 0, y: 0 } to reset the position to system default.

// Removed in Electron 28
win.setTrafficLightPosition({ x: 10, y: 10 });
win.setTrafficLightPosition({ x: 0, y: 0 });

// Replace with
win.setWindowButtonPosition({ x: 10, y: 10 });
win.setWindowButtonPosition(null);

Removed: BrowserWindow.getTrafficLightPosition()​

BrowserWindow.getTrafficLightPosition() has been removed, the BrowserWindow.getWindowButtonPosition() API should be used instead which returns null instead of { x: 0, y: 0 } when there is no custom position.

// Removed in Electron 28
const pos = win.getTrafficLightPosition();
if (pos.x === 0 && pos.y === 0) {
  // No custom position.
}

// Replace with
const ret = win.getWindowButtonPosition();
if (ret === null) {
  // No custom position.
}

Removed: ipcRenderer.sendTo()​

The ipcRenderer.sendTo() API has been removed. It should be replaced by setting up a MessageChannel between the renderers.

The senderId and senderIsMainFrame properties of IpcRendererEvent have been removed as well.

Removed: app.runningUnderRosettaTranslation​

The app.runningUnderRosettaTranslation property has been removed. Use app.runningUnderARM64Translation instead.

// Removed
console.log(app.runningUnderRosettaTranslation);
// Replace with
console.log(app.runningUnderARM64Translation);

Fin de soporte para 25.x.y​

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

What's Next​

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.

You can find Electron's public timeline here.

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

Reflexionando sobre las mejoras y cambios en el ecosistema para desarrolladores de Electron en 2023.

¡En los últimos meses, hemos estado cocinando algunos cambios en el ecosistema de Electron para sobrecargar la experiencia de desarrollador para aplicaciones de Electron! Aquí hay un breve resumen de las últimas adiciones directamente de Electron HQ.

Electron Forge 7 y más allá​

Electron Forge 7 — la versión más reciente de nuestra herramienta todo en uno para empacar y distribuir aplicaciones de Electron — ya está disponible.

Mientras Forge 6 fue una reescritura completa de v5, v7 es más pequeña en alcance, pero aún contiene algunos cambios de ruptura. Siguiendo adelante, continuaremos publicando versiones importantes de Forge a medida que se necesite realizar cambios relevantes.

Para más detalles, vea el listado completo de cambios de Forge v7.0.0 en GitHub.

Cambios notables​

• Se ha cambiado a notarytool para la notarización de macOS: En 2023-11-01, Apple puso fin a la altool heredada para la notarización de macOS y este lanzamiento la elimina de Electron Forge completamente.
• Versión mínima de Node.js aumentada a v16.4.0: Con este lanzamiento, hemos establecido la versión mínima requerida de Node.js a 16.4.0.
• Se ha eliminado el soporte para electron-prebuilt y electron-prebuilt-compile: electron-prebuilt era el nombre original para el módulo npm de Electron, pero se ha reemplazado por electron en v1.3.1. electron-prebuilt-console era una alternativa a ese binario que viene con características DX mejoradas, pero eventualmente fue abandonado como proyecto.

Highlights​

• Editor de Google Cloud Storage: ¡Como parte de nuestro compromiso de mejorar el soporte de la actualización automática estática, Electron Forge ahora soporta la publicación directa a Google Cloud Storage!
• Soporte para ESM forge.config.js: Electron Forge ahora soporta los archivos forge.config.js. (P.D. Esperamos el soporte de puntos de entrada ESM en Electron 28.)
• Makers ahora se ejecutan en paralelo: En Electron Forge 6, Makers se ejecutó secuencialmente para el ✨ legado ✨. Desde entonces, hemos probado paralelización para el paso de hacer sin efectos secundarios adversos, ¡así que deberías ver una aceleración al construir múltiples objetivos para la misma plataforma!

Mejor soporte estático y actualizaciones automáticas​

Squirrel.Windows y Squirrel.Mac son tecnologías actualizadoras específicas de la plataforma que respaldan el módulo autoUpdater integrado de Electron. Ambos proyectos soportan actualizaciones automáticas mediante dos métodos:

• Un servidor de actualizaciones compatible con Squirrel
• Una URL de manifiesto alojada en un proveedor de almacenamiento estático (por ejemplo, AWS, Google Cloud Platform, Microsoft Azure, etc.)

El método de actualización del servidor ha sido tradicionalmente el método recomendado para las aplicaciones Electron (y proporciona personalización adicional de la lógica de actualización), pero tiene un lado inferior importante — requiere que las aplicaciones mantengan su propia instancia del servidor si son de código cerrado.

Por otra parte, el método de almacenamiento estático siempre ha sido posible, pero fue indocumentado dentro de Electron y mal soportado en los paquetes de herramientas de Electron.

Con un gran trabajo de @MarshallOfSound, la historia de actualizaciones para actualizaciones automáticas de aplicaciones sin servidor se ha simplificado drásticamente:

• Los creadores Zip y Squirrel.Windows de Electron Forge ahora pueden configurarse para mostrar los manifiestos de actualización compatibles con autoUpdater.
• Una nueva versión principal de update-electron-app (v2.0.0) ahora puede leer estos manifiestos generados como una alternativa al servidor update.electronjs.org.

Una vez que sus Makers y Publishers estén configurados para cargar manifiestos de actualización a la nube de almacenamiento de archivos, puede habilitar actualizaciones automáticas con sólo unas pocas líneas de configuración:

const { updateElectronApp, UpdateSourceType } = require('update-electron-app');

updateElectronApp({
  updateSource: {
    type: UpdateSourceType.StaticStorage,
    baseUrl: `https://my-manifest.url/${process.platform}/${process.arch}`,
  },
});

El universo extendido @electron/​

Cuando Electron comenzó por primera vez, la comunidad publicó muchos paquetes para mejorar la experiencia de desarrollar, empaquetar y distribuir aplicaciones de Electron. Con el tiempo, muchos de estos paquetes fueron incorporados a la organización GitHub de Electron, y el equipo central asumió la carga de mantenimiento.

En 2022, comenzamos a unificar todas estas herramientas de primer partido bajo el nombre de @electron/ en npm. Este cambio significa que los paquetes que solían ser electron-foo ahora son @electron/foo en npm, y los repositorios que antes se llamaban electron/electron-foo ahora son electron/foo en GitHub. Estos cambios ayudan claramente a fomentar proyectos de primera parte a partir de proyectos de tierras de usuario. Esto incluye muchos paquetes comúnmente usados, como:

• @electron/asar
• @electron/fuses
• @electron/get
• @electron/notarize
• @electron/osx-sign
• @electron/packager
• @electron/rebuild
• @electron/remote
• @electron/symbolicate-mac
• @electron/universal

Siguiendo adelante, todos los paquetes de la primera parte que liberemos también estarán en el espacio de nombre de @electron/. Hay dos excepciones a esta regla:

• El núcleo de Electron continuará publicándose bajo el paquete electron.
• Electron Forge continuará publicando todos sus paquetes monorepo bajo el espacio de nombre de @electron-forge/.

Presentando @electron/windows-sign​

A partir de 2023-06-01, los estándares de la industria comenzaron a requerir que las claves para que los certificados de firma de código de Windows se almacenaran en hardware compatible con FIPS.

En la práctica, esto significó que la firma de código se volvió mucho más difícil para las aplicaciones que construyen y firman en entornos IC, ya que muchas herramientas de Electron toman un archivo de certificado y contraseña como parámetros de configuración e intentan firmar desde allí usando lógica codificada.

Esta situación ha sido un punto de dolor común para los desarrolladores de Electron que es la razón por la que hemos estado trabajando en una mejor solución que aísla la firma de código de Windows en su propio paso independiente, similar a lo que @electron/osx-sign hace en macOS.

En el futuro, planeamos integrar plenamente este paquete en la cadena de herramientas Electron Forge, pero actualmente vive por su cuenta. El paquete está actualmente disponible para la instalación en npm install --save-dev @electron/windows-sign y puede usarse programáticamente o a través de CLI.

¡Inténtalo y danos tu opinión en el seguimiento de incidencias del repositorio!

What's next?​

Estaremos entrando en nuestro período anual de silencio de diciembre el mes que viene. Mientras lo hacemos, estaremos pensando en cómo podemos mejorar aún más la experiencia de desarrollo de Electron en 2024.

¿Hay algo que te gustaría ver trabajar en el futuro? ¡Déjanos saber!

El proyecto de Electron se pausará para el mes de diciembre de 2023, para luego regresar a toda velocidad en enero de 2024.

vía GIPHY

Lo que será igual en diciembre​

1. Los lanzamientos de día cero y los lanzamientos principales relacionados con la seguridad se publicarán según sea necesario. Los incidentes de seguridad se deben reporar a través de SECURITY.md.
2. Los reportes relacionados con el Código de conducta continuarán.

Lo que será diferente en diciembre​

1. Electron 28.0.0 se publicará el 5 de diciembre. Luego de Electron 28, no se realizará el lanzamiento de versiones estables en diciembre.
2. No Nightly and Alpha releases for the last two weeks of December.
3. Con algunas excepciones, no se realizará la revisión o fusión de pull requests.
4. No se actualizará el rastreador de incidencias en ningún repositorio.
5. No se ayudará con la depuración en Discord por parte de los encargados.
6. No se publicarán actualizaciones de contenido en las redes sociales.

Avanzando​

This is our third year running our quiet period experiment, and we've had a lot of success so far in balancing a month of rest with maintaining our normal release cadence afterwards. Therefore, we've decided to make this a regular part of our release calendar going forward. We'll still be putting a reminder into the last stable release of every calendar year.

See you all in 2024!

¡Electron 27.0.0 ha sido liberado! Incluye actualizaciones a Chromium 118.0.5993.32, V8 11.8, y Node.js 18.17.1.

El equipo de Electron esta emocionado de anunciar el lanzamiento de Electron 27.0.0! You can install it with npm via npm install electron@latest or download it from our releases website. Continue reading for details about this release.

¡Si tienes algún comentario, por favor compártelo con nosotros por medio de Twitter o Mastodon, o únete a nuestra comunidad en Discord! Bugs and feature requests can be reported in Electron's issue tracker.

Notable Changes​

Stack Changes​

• Chromium 118.0.5993.32
  • Nuevo en Chrome 118
  • Nuevo en DevTools 118
• Node.js 18.17.1
  • Node 18.17.1 blog post
  • Node 18.17.0 blog post
• V8 11.8

Restaurar archivos borrados​

Eliminado: soporte para macOS 10.13 / 10.14​

macOS 10.13 (High Sierra) and macOS 10.14 (Mojave) are no longer supported by Chromium.

Las versiones antiguas de Electron continuarán funcionando en estos sistemas operativos, pero macOS 10.15 (Catalina) o versiones superiores son requeridas para ejecutar Electron v27.0.0 o superior.

Deprecado: ipcRenderer.sendTo()​

La API de ipcRenderer.sendTo() es obsoleta. Esta se debería reemplazar configurando un MessageChannel entre los renderizadores.

Las propiedades senderId y senderIsMainFrame de IpcRendererEvent también están obsoletas.

Eliminado: eventos de esquema de color en systemPreferences​

Los siguientes eventos de systemPreferences han sido eliminados:

• inverted-color-scheme-changed
• high-contrast-color-scheme-changed

Use el nuevo evento updated en el módulo nativeTheme en su lugar.

// Eliminado
systemPreferences.on('inverted-color-scheme-changed', () => {
  /* ... */
});
systemPreferences.on('high-contrast-color-scheme-changed', () => {
  /* ... */
});

// Reemplazar con
nativeTheme.on('updated', () => {
  /* ... */
});

Eliminado: webContents.getPrinters​

El método webContents.getPrinters ha sido eliminado. Use webContents.getPrintersAsync instead.

const w = new BrowserWindow({ show: false });

// Eliminado
console.log(w.webContents.getPrinters());
// Reemplazar con
w.webContents.getPrintersAsync().then((printers) => {
  console.log(printers);
});

Eliminado: systemPreferences.{get,set}AppLevelAppearance y systemPreferences.appLevelAppearance​

Los métodos de systemPreferences.getAppLevelAppearance y systemPreferences.setAppLevelAppearance han sido eliminados, al igual que la propiedad de systemPreferences.appLevelAppearance. Use the nativeTheme module instead.

// Eliminado
systemPreferences.getAppLevelAppearance();
// Reemplazar con
nativeTheme.shouldUseDarkColors;

// Eliminado
systemPreferences.appLevelAppearance;
// Reemplazar con
nativeTheme.shouldUseDarkColors;

// Eliminado
systemPreferences.setAppLevelAppearance('dark');
// Reemplazar con
nativeTheme.themeSource = 'dark';

Eliminado: valor alternate-selected-control-text para systemPreferences.getColor​

El valor alternate-selected-control-text para systemPreferences.getColor ha sido eliminado. Use selected-content-background instead.

// Eliminado
systemPreferences.getColor('alternate-selected-control-text');
// Reemplazar con
systemPreferences.getColor('selected-content-background');

Nuevas características​

• Se ha agregado la API de ajustes de transparencia de accesibilidad de la aplicación #39631
• Se ha agregado el soporte para las APIs de extensión chrome.scripting #39675
• Se ha activado WaylandWindowDecorationspor defecto #39644

Fin de soporte para 24.x.y​

Electron 24.x.y ha alcanzado el fin de soporte según la política de soporte del proyecto. Developers and applications are encouraged to upgrade to a newer version of Electron.

Fin del soporte extendido para 22.x.y​

A inicios de este año, el equipo de Electron extendió la fecha del fin de ciclo de vida de Electron 22 desde el 30 de mayo de 2023 hasta el 10 de octubre de 2023, para que coincida con el soporte extendido de Chrome para Windows 7/8/8.1 (ver Hasta la vista, Windows 7/8/8.1 para más detalles).

Electron 22.x.y ha alcanzado el fin del soporte, de acuerdo a la política de soporte del proyecto y esta extensión de soporte. Esto eliminará el soporte a las últimas tres versiones estables y finalizará el soporte oficial para Windows 7/8/8.1.

What's Next​

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.

You can find Electron's public timeline here.

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

Ha pasado más de una semana desde CVE-2023-4863: Se ha hecho público el desbordamiento del búfer Heap en WebP, lo que ha causado una avalancha de nuevos lanzamientos en programas para el renderizado de imágenes webp: macOS, iOS, Chrome, Firefox y varias distribuciones Linux han recibido actualizaciones. Tras las investigaciones realizadas por Citizen Lab, se ha descubierto que un iPhone utilizado por una "organización de la sociedad civil unicada en Washington DC" estuvo bajo ataque por medio de una vulnerabilidad de cero-clicks en iMessage.

Electron, también, entró en acción y publicó nuevas versiones el mismo día: Si tu aplicación renderiza cualquier contenido proporcionado por el usuario, debes actualizar tu versión de Electron - v27.0.0-beta.2, v26.2.1, v25.8.1, v24.8.3 y v22.3.23, todas contienen una versión corregida de libwebp, la librería responsable de renderizar imágenes webp.

Ahora que estamos enterados de que una interacción tan inocente como "renderizar una imagen" es una actividad potencialmente peligrosa, aprovechamos esta oportunidad para recordar a todos que Electron incluye un sandbox de procesos que limita el radio de explosión del siguiente gran ataque — sin importar lo que sea.

El sandbox ha estado disponible desde Electron v1 y está activado por defecto en v20, pero sabemos que varias aplicaciones (especialmente aquellas que están disponibles desde hace tiempo) podrían tener un sandbox: false en cualquier parte del código – o un nodeIntegration: true que, igualmente, desactiva el sandbox cuando no hay un ajuste de sandbox explícito. Eso es comprensible: si has estado con nosotros durante un largo tiempo, probablemente has disfrutado el poder de lanzar un require("child_process") o require("fs") en el mismo código que ejecuta tu HTML/CSS.

Antes de hablar sobre cómo migrar al sandbox, primero discutamos por qué lo quieres.

El sandbox pone una jaula dura alrededor de todos los procesos de renderizado, garantizando que sin importar lo que suceda dentro, el código es ejecutado en un entorno restringido. Como concepto, es mucho más viejo que Chromium y es proporcionado como una característica en todos los sistemas operativos. El sandbox de Electron y Chromium es construido en base a estas características del sistema. Incluso si nunca has mostrado contenido generado por el usuario, deberías considerar la posibilidad de que tu renderizado puede verse comprometido: Escenarios tan complejos como los ataques a la cadena de suministros y tan sencillos como pequeños errores, pueden causar que tu renderizado realice acciones que no planeabas.

El entorno de pruebas hace que ese escenario sea mucho menos aterrador: un proceso dentro consigue usar libremente ciclos de CPU y memoria — eso es todo. Los procesos no pueden escribir en el disco o mostrar sus propias ventanas. En el caso de nuestro libwep error, el sandbox se asegura de que un atacante no pueda instalar o ejecutar malware. De hecho, en el caso del ataque Pegasus original contra el iPhone, de los empleados. el ataque se dirigió específicamente a un proceso de imagen que no es de arena para obtener acceso al teléfono, rompiendo primero los límites del iMessage normalmente encendido. Cuando un CVE como el de este ejemplo es anunciado, todavía tienes que actualizar tus aplicaciones Electron a una versión segura, pero mientras tanto, la cantidad de daño que un atacante puede causar es muy limitada.

Migrar una aplicación de vainilla Electron de sandbox: false a sandbox: true es una empresa. Lo sé, porque a pesar de haber escrito personalmente el primer borrador de las Directrices de Seguridad Electron, No he conseguido migrar una de mis propias aplicaciones para usarla. Esto ha cambiado este fin de semana y les recomiendo que lo cambien también.

Hay dos cosas que tienes que tomar en cuenta:

1. If you’re using Node.js code in either preload scripts or the actual WebContents, you need to move all that Node.js interaction to the main process (or, if you are fancy, a utility process). Given how powerful renderers have become, chances are high that the vast majority of your code doesn’t really need refactoring.

   Consult our documentation on Inter-Process Communication. In my case, I moved a lot of code and wrapped it in ipcRenderer.invoke() and ipcMain.handle(), but the process was straightforward and quickly done. Be a little mindful of your APIs here - if you build an API called executeCodeAsRoot(code), the sandbox won't protect your users much.

2. Since enabling the sandbox disables Node.js integration in your preload scripts, you can no longer use require("../my-script"). In other words, your preload script needs to be a single file.

   There are multiple ways to do that: Webpack, esbuild, parcel, and rollup will all get the job done. I used Electron Forge’s excellent Webpack plugin, users of the equally popular electron-builder can use electron-webpack.

All in all, the entire process took me around four days — and that includes a lot of scratching my head at how to wrangle Webpack’s massive power, since I decided to use the opportunity to refactor my code in plenty of other ways, too.