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!

¿Qué sigue?​

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.

¡Electron 26.0.0 ha sido liberado! Incluye actualizaciones a Chromium 116.0.5845.62, V8 11.2, y Node.js 18.16.1. ¡Lea a continuación para más detalles!

El equipo de Electron esta emocionado de anunciar el lanzamiento de Electron 26.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 join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

Notable Changes​

Stack Changes​

• Chromium 116.0.5845.62
  • Nuevo en Chrome 116
  • Nuevo en DevTools 116
• Node.js 18.16.1
  • Node 18.16.1 blog post
• V8 11.2

Restaurar archivos borrados​

Deprecado: webContents.getPrinters​

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

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

// Deprecated
console.log(w.webContents.getPrinters());
// Replace with
w.webContents.getPrintersAsync().then((printers) => {
  console.log(printers);
});

Deprecated: systemPreferences.{get,set}AppLevelAppearance and systemPreferences.appLevelAppearance​

The systemPreferences.getAppLevelAppearance and systemPreferences.setAppLevelAppearance methods have been deprecated, as well as the systemPreferences.appLevelAppearance property. Use the nativeTheme module instead.

// Deprecated
systemPreferences.getAppLevelAppearance();
// Replace with
nativeTheme.shouldUseDarkColors;

// Deprecated
systemPreferences.appLevelAppearance;
// Replace with
nativeTheme.shouldUseDarkColors;

// Deprecated
systemPreferences.setAppLevelAppearance('dark');
// Replace with
nativeTheme.themeSource = 'dark';

Deprecated: alternate-selected-control-text value for systemPreferences.getColor​

The alternate-selected-control-text value for systemPreferences.getColor has been deprecated. Use selected-content-background instead.

// Deprecated
systemPreferences.getColor('alternate-selected-control-text');
// Replace with
systemPreferences.getColor('selected-content-background');

Nuevas características​

• Added safeStorage.setUsePlainTextEncryption and safeStorage.getSelectedStorageBackend api. #39107
• Added safeStorage.setUsePlainTextEncryption and safeStorage.getSelectedStorageBackend api. #39155
• Added senderIsMainFrame to messages sent via ipcRenderer.sendTo(). #39206
• Added support for flagging a Menu as being keyboard initiated. #38954

Fin de soporte para 23.x.y​

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

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.

¡Electron 25.0.0 ha sido liberado! Incluye actualizaciones a Chromium 114, V8 11.4, y Node.js 18.15.0. ¡Lea a continuación para más detalles!

El equipo de Electron esta emocionado de anunciar el lanzamiento de Electron 25.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 join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

Notable Changes​

Highlights​

• Se implementó net.fetch en el módulo net de Electron, usando la pila de red de Chromium. Esto difiere del fetch() de Node, que usa la pila HTTP de Node.js. Ver #36733 y #36606.
• Se añadió protocol.handle, que reemplaza y depreca a protocol.{register,intercept}{String,Buffer,Stream,Http,File}Protocol. #36674
• Se extiende el soporte para Electron 22, para que coincida con el plan de desaprobación de Windows 7/8/8.1 de Microsoft. Ver detalles adicionales al final de esta entrada de blog.

Stack Changes​

• Chromium 114
  • Nuevo en Chrome 114
  • Nuevo en Chrome 113
  • Nuevo en DevTools 114
  • Nuevo en DevTools 113
• Node.js 18.15.0
  • Node 18.15.0 blog post
• V8 11.4

Restaurar archivos borrados​

Deprecado: protocol.{register,intercept}{Buffer,String,Stream,File,Http}Protocol​

The protocol.register*Protocol and protocol.intercept*Protocol methods have been replaced with protocol.handle.

El nuevo método puede registrar un nuevo protocolo o interceptar un protocolo existente, y las respuestas pueden ser de cualquier tipo.

// Obsoleto en Electron 25
protocol.registerBufferProtocol('some-protocol', () => {
  callback({ mimeType: 'text/html', data: Buffer.from('<h5>Response</h5>') });
});

// Reemplazar con
protocol.handle('some-protocol', () => {
  return new Response(
    Buffer.from('<h5>Response</h5>'), // También podría ser un string o ReadableStream.
    { headers: { 'content-type': 'text/html' } }
  );
});

// Obsoleto en Electron 25
protocol.registerHttpProtocol('some-protocol', () => {
  callback({ url: 'https://electronjs.org' });
});

// Reemplazar con
protocol.handle('some-protocol', () => {
  return net.fetch('https://electronjs.org');
});

// Obsoleto en Electron 25
protocol.registerFileProtocol('some-protocol', () => {
  callback({ filePath: '/path/to/my/file' });
});

// Reemplazar con
protocol.handle('some-protocol', () => {
  return net.fetch('file:///path/to/my/file');
});

Deprecado: BrowserWindow.setTrafficLightPosition(position)​

BrowserWindow.setTrafficLightPosition(position) ahora es obsoleto, la API BrowserWindow.setWindowButtonPosition(position) debe ser usada en su lugar, la cual acepta null en vez de { x: 0, y: 0 } para restablecer la posición al valor predeterminado del sistema.

// Obsoleto en Electron 25
win.setTrafficLightPosition({ x: 10, y: 10 });
win.setTrafficLightPosition({ x: 0, y: 0 });

// Reemplazar con
win.setWindowButtonPosition({ x: 10, y: 10 });
win.setWindowButtonPosition(null);

Deprecado: BrowserWindow.getTrafficLightPosition()​

BrowserWindow.getTrafficLightPosition() ahora es obsoleto, la API BrowserWindow.getWindowButtonPosition() debe ser usada en su lugar, la cual retorna null en vez de { x: 0, y: 0 } cuando no hay una posición personalizada.

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

// Reemplazar con
const ret = win.getWindowButtonPosition();
if (ret === null) {
  // Sin posición personalizada.
}

Nuevas características​

• Se añadió net.fetch(). #36733
  • net.fetch soporta solicitudes a las URL file: y a protocolos personalizados con protocol.register*Protocol. #36606
• Se añadieron las APIs BrowserWindow.set/getWindowButtonPosition. #37094
• Se añadió protocol.handle, que reemplaza y depreca a protocol.{register,intercept}{String,Buffer,Stream,Http,File}Protocol. #36674
• Se añadió el evento will-frame-navigate en webContents y el tag <webview>, que dispara cada fotograma dentro de la jerarquía de fotogramas que se intenta navegar. #34418
• Added initiator information to navigator events. Esta información permite distinguir window.open de un frame padre causando una navegación, en lugar de una navegación iniciada por hijos. #37085
• Se añadió net.resolveHost que resuelve los hosts usando el objeto defaultSession. #38152
• Se añadió el nuevo evento 'did-resign-active' en app. #38018
• Added several standard page size options to webContents.print(). #37159
• Added the enableLocalEcho flag to the session handler ses.setDisplayMediaRequestHandler() callback for allowing remote audio input to be echoed in the local output stream when audio is a WebFrameMain. #37315
• Se añadió información de gestión térmica a powerMonitor. #38028
• Permite pasar una ruta absoluta a la API session.fromPath(). #37604
• Expone el evento audio-state-changed en webContents. #37366

Soporte Continuado 22.x.y​

As noted in Farewell, Windows 7/8/8.1, Electron 22's (Chromium 108) planned end of life date will be extended from May 30, 2023 to October 10, 2023. The Electron team will continue to backport any security fixes that are part of this program to Electron 22 until October 10, 2023. La fecha de soporte de octubre sigue las fechas de soporte extendidas tanto de Chromium como de Microsoft. On October 11, the Electron team will drop support back to the latest three stable major versions, which will no longer support 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.

¡Electron 24.0.0 ha sido liberado! Incluye actualizaciones a Chromium 112.0.5615.49, V8 11.2, y Node.js 18.14.0. ¡Lea a continuación para más detalles!

El equipo de Electron esta emocionado de anunciar el lanzamiento de Electron 24.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 join our community Discord! Bugs and feature requests can be reported in Electron's issue tracker.

Notable Changes​

Stack Changes​

• Chromium 112.0.5615.49
  • Nuevo en Chrome 112
  • Nuevo en Chrome 111
  • New in DevTools 112
  • New in DevTools 111
• Node.js 18.14.0
  • Node 18.14.0 blog post
• V8 11.2

Restaurar archivos borrados​

API modificada: nativeImage.createThumbnailFromPath(path, size)​

The maxSize parameter has been changed to size to reflect that the size passed in will be the size the thumbnail created. Previously, Windows would not scale the image up if it were smaller than maxSize, and macOS would always set the size to maxSize. Behavior is now the same across platforms.

// a 128x128 image.
const imagePath = path.join('path', 'to', 'capybara.png');

// Scaling up a smaller image.
const upSize = { width: 256, height: 256 };
nativeImage.createThumbnailFromPath(imagePath, upSize).then((result) => {
  console.log(result.getSize()); // { width: 256, height: 256 }
});

// Scaling down a larger image.
const downSize = { width: 64, height: 64 };
nativeImage.createThumbnailFromPath(imagePath, downSize).then((result) => {
  console.log(result.getSize()); // { width: 64, height: 64 }
});

Nuevas características​

• Added the ability to filter HttpOnly cookies with cookies.get(). #37365
• Added logUsage to shell.openExternal() options, which allows passing the SEE_MASK_FLAG_LOG_USAGE flag to ShellExecuteEx on Windows. The SEE_MASK_FLAG_LOG_USAGE flag indicates a user initiated launch that enables tracking of frequently used programs and other behaviors. #37291
• Added types to the webRequest filter, adding the ability to filter the requests you listen to.#37427
• Added a new devtools-open-url event to webContents to allow developers to open new windows with them. #36774
• Added several standard page size options to webContents.print(). #37265
• Added the enableLocalEcho flag to the session handler ses.setDisplayMediaRequestHandler() callback for allowing remote audio input to be echoed in the local output stream when audio is a WebFrameMain. #37528
• Allow an application-specific username to be passed to inAppPurchase.purchaseProduct(). #35902
• Exposed window.invalidateShadow() to clear residual visual artifacts on macOS. #32452
• Whole-program optimization is now enabled by default in electron node headers config file, allowing the compiler to perform opimizations with information from all modules in a program as opposed to a per-module (compiland) basis. #36937
• SystemPreferences::CanPromptTouchID (macOS) now supports Apple Watch. #36935

Fin de soporte para 21.x.y​

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

As noted in Farewell, Windows 7/8/8.1, Electron 22's (Chromium 108) planned end of life date will be extended from May 30, 2023 to October 10, 2023. The Electron team will continue to backport any security fixes that are part of this program to Electron 22 until October 10, 2023.

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.

El primer commit en el repositorio electron/electron fue el 13 de marzo de 2013¹.

10 años y 27.147 commits más de 1192 colaboradores únicos después, Electron se ha convertido en uno de los frameworks más populares para crear aplicaciones de escritorio hoy en día. Este hito es la oportunidad perfecta para celebrar y reflexionar sobre nuestro viaje hasta ahora, y para compartir lo que hemos aprendido en el camino.

No estaríamos aquí hoy sin todos los que han dedicado su tiempo y esfuerzo a contribuir al proyecto. Aunque los commits del código fuente son siempre las contribuciones más visibles, también tenemos que reconocer el esfuerzo de la gente que informa de errores, mantiene módulos de usuario, proporciona documentación y traducciones, y participa en la comunidad Electron a través del ciberespacio. Cada contribución tiene un valor incalculable para nosotros como mantenedores.

Antes de continuar con el resto de la entrada del blog: gracias. ❤️

¿Cómo hemos llegado hasta aquí?​

Atom Shell se construyó como la columna vertebral para el editor Atomde GitHub, que se lanzó en beta pública en abril de 2014. Se construyó desde cero como alternativa a los frameworks de escritorio basados en web disponibles en ese momento (node-webkit y Chromium Embedded Framework). Tenía una característica estrella: contiene Node.js y Chromium para proporcionar un potente tiempo de ejecución de escritorio para tecnologías web.

Al cabo de un año, Atom Shell empezó a crecer enormemente en capacidades y popularidad. Grandes compañías, startups y desarrolladores individuales habían empezado a construir aplicaciones con él (algunos de los primeros adoptores incluyen Slack, GitKraken, y WebTorrent), y el proyecto fue renombrado correctamente a Electron.

Desde entonces, Electron no ha parado de crecer. Aquí tienes un vistazo a nuestro recuento semanal de descargas con el tiempo, cortesía de npmtrends.com:

Electron v1 se lanzó en 2016, prometiendo una mayor estabilidad de la API y mejores documentos y herramientas. Electron v2 se lanzó en 2018 e introdujo el versionado semántico, lo que facilita a los desarrolladores de Electron a los desarrolladores hacer un seguimiento del ciclo de lanzamiento.

En Electron v6, cambiamos a una cadencia regular de lanzamientos principales de 12 semanas para ajustarnos a la de Chromium. Esta decisión supuso un cambio de mentalidad para el proyecto, haciendo que "tener la versión más actualizada de Chromium" pasara de ser un "nice-to-have" a una prioridad. Esto ha reducido la cantidad de deuda técnica entre actualizaciones, lo que nos facilita mantener Electron actualizado y seguro.

Desde entonces, hemos sido una máquina bien engrasada, lanzando una nueva versión de Electron el mismo día que cada versión estable de Chromium. Cuando Chromium aceleró su calendario de lanzamientos a 4 semanas en 2021, pudimos encogernos de hombros y aumentar nuestra cadencia de lanzamiento a 8 semanas.

Ahora estamos en Electron v23 (y contando), y seguimos dedicados a construir el mejor tiempo de ejecución para aplicaciones de escritorio multiplataforma. Incluso con el auge de las herramientas para desarrolladores de JavaScript en desarrolladores de JavaScript en los últimos años, Electron se ha mantenido estable y ha de escritorio. Las aplicaciones de Electron son omnipresentes hoy en día: puedes programar con Visual Studio Code, diseñar con Figma, comunicarte con Slack y tomar notas con Notion (entre muchos otros casos de uso). Estamos increíblemente orgullosos de este logro y agradecidos con todos aquellos que lo hicieron posible.

¿Qué aprendimos en el camino?​

El camino hacia la marca de la década ha sido largo y sinuoso. Aquí hay algunas claves que nos han ayudado a mantener un proyecto de código abierto grande y sostenible.

Escalando la toma de decisiones distribuida con un modelo de gobernanza​

Uno de los desafíos que tuvimos que superar fue manejar la dirección a largo plazo del proyecto una vez que Electron explotó en popularidad. ¿Cómo manejamos ser un equipo de varias docenas de ingenieros distribuidos en diferentes empresas, países y zonas horarias?

En los primeros días, el grupo de mantenimiento de Electron dependía de la coordinación informal, lo que es rápido y ligero para proyectos más pequeños, pero no es escalable para una colaboración más amplia. En 2019, cambiamos a un modelo de gobernanza donde diferentes grupos de trabajo tienen áreas formales de responsabilidad. Esto ha sido fundamental para optimizar los procesos y asignar porciones de propiedad del proyecto a mantenedores específicos. ¿De qué es responsable cada Grupo de Trabajo (WG) en la actualidad?

• Sacar las versiones de Electron (Releases WG)
• Actualizar Chromium y Node.js (Upgrades WG)
• Supervisar el diseño de la API pública (API WG)
• Mantener Electron seguro (Security WG)
• Administrar el sitio web, documentación y herramientas (Ecosystem WG)
• Alcanzar a la comunidad y a las empresas (Outreach WG)
• Moderación de la comunidad (Community & Safety WG)
• Mantener nuestra infraestructura de compilación, herramientas de mantenedor y servicios en la nube (Infrastructure WG)

Alrededor de la misma época en que cambiamos al modelo de gobernanza, también trasladamos la propiedad de Electron de GitHub a la OpenJS Foundation. Aunque el equipo central original todavía funciona en Microsoft hoy, son sólo parte de un grupo de colaboradores más grande que forman la gobernanza de Electron.²

Si bien este modelo no es perfecto, nos ha funcionado bien a través de una pandemia global y vientos macroeconómicos en curso. En el futuro, planeamos renovar la carta de gobernanza para guiarnos a través de la segunda década de Electron.

Comunidad​

La parte de la comunidad de código abierto es difícil, especialmente cuando tu equipo de divulgación está compuesto por una docena de ingenieros disfrazados con una gabardina que dice "gerente de comunidad". Dicho esto, ser un proyecto de código abierto grande significa que tenemos muchos usuarios, y aprovechar su energía para construir un ecosistema de usuarios para Electron es una parte crucial para mantener la salud del proyecto.

¿Qué hemos estado haciendo para desarrollar nuestra presencia en la comunidad?

Construyendo comunidades​

• En 2020, lanzamos nuestro servidor de Discord. Anteriormente teníamos una sección en el foro de Atom, pero decidimos tener una plataforma de mensajería más informal para tener un espacio para discusiones entre mantenedores y desarrolladores de Electron, así como para obtener ayuda general de depuración.
• En 2021, establecimos el grupo de usuarios de Electron China con la ayuda de @BlackHole1. Este grupo ha sido fundamental para el crecimiento de Electron en usuarios de la floreciente escena tecnológica de China, proporcionando un espacio para que colaboren en ideas y discutan sobre Electron fuera de nuestros espacios en inglés. También nos gustaría agradecer a cnpm por su trabajo en apoyar las versiones nocturnas de Electron en su espejo chino para npm.

Participar en programas de código abierto de alta visibilidad​

• Desde 2019 hemos estado celebrando el Hacktoberfest cada año. Hacktoberfest es una celebración anual de código abierto organizada por DigitalOcean, y desde 2019 hemos estado participando en ella. Cada año recibimos docenas de entusiastas contribuyentes que buscan dejar su huella en el software de código abierto.
• En 2020, participamos en la primera iteración de Google Season of Docs, donde trabajamos con @bandantonio para reorganizar el flujo del tutorial de usuario nuevo de Electron.
• En 2022, mentorizamos a un estudiante en el programa Google Summer of Code por primera vez. @aryanshridhar did some awesome work to refactor Electron Fiddle's core version loading logic and migrate its bundler to webpack.

¡Automatiza todas las cosas!​

Hoy en día, la gobernanza de Electron cuenta con alrededor de 30 mantenedores activos. Menos de la mitad de nosotros somos contribuidores a tiempo completo, lo que significa que hay mucho trabajo para compartir. ¿Cuál es nuestro truco para mantener todo funcionando sin problemas? Nuestro lema es que las computadoras son baratas y el tiempo humano es caro. Al estilo típico de los ingenieros, hemos desarrollado una serie de herramientas de soporte automatizadas para facilitar nuestras vidas.

Not Goma​

La base de código principal de Electron es un gigante de código en C++, y los tiempos de compilación siempre han sido un factor limitante en la velocidad con la que podemos implementar correcciones de errores y nuevas funcionalidades. En 2020, implementamos Not Goma, una plataforma personalizada específica para Electron para el servicio de compilador distribuido de Google llamado Goma. Not Goma procesa las solicitudes de compilación de las máquinas autorizadas de los usuarios y distribuye el proceso en cientos de núcleos en el backend. Además, Not Goma también almacena en caché el resultado de la compilación para que alguien más que compile los mismos archivos solo necesite descargar el resultado precompilado.

Desde que lanzamos Not Goma, los tiempos de compilación para los mantenedores han disminuido de varias horas a unos pocos minutos. ¡Una conexión estable a internet se convirtió en el requisito mínimo para que los contribuyentes pudieran compilar Electron!

Autenticación de Factor Continuo​

Autenticación de Factor Continuo (CFA) es una capa de automatización en torno al sistema de autenticación de dos factores (2FA) de npm que combinamos con semantic-release para gestionar lanzamientos seguros y automatizados de nuestros diversos paquetes npm de @electron/.

Mientras que semantic-release ya automatiza el proceso de publicación de paquetes de npm, requiere desactivar la autenticación de dos factores o pasar un token secreto que evita esta restricción.

Construimos CFA para entregar una contraseña de un solo uso basada en el tiempo (TOTP) para el 2FA de npm a trabajos de integración continua (CI) arbitrarios, lo que nos permite aprovechar la automatización de semantic-release manteniendo la seguridad adicional de la autenticación de dos factores.

Usamos CFA con una interfaz integrada en Slack, lo que permite a los mantenedores validar la publicación de paquetes desde cualquier dispositivo en el que tengan Slack, siempre y cuando tengan su generador de TOTP a mano.

Sheriff​

Sheriff es una herramienta de código abierto que escribimos para automatizar la gestión de permisos en GitHub, Slack y Google Workspace.

La propuesta de valor clave de Sheriff es que la gestión de permisos debe ser un proceso transparente. Utiliza un único archivo de configuración YAML que designa los permisos en todos los servicios mencionados anteriormente. Con Sheriff, obtener el estado de colaborador en un repositorio o crear una nueva lista de correo es tan fácil como obtener la aprobación y la fusión de una PR.

Sheriff también cuenta con un registro de auditoría que se publica en Slack, alertando a los administradores cuando ocurre actividad sospechosa en cualquier lugar de la organización Electron.

... y todos nuestros bots de GitHub​

GitHub es una plataforma con una amplia extensibilidad de API y un marco de aplicación de bot de "first-party" llamado Probot. Para ayudarnos a enfocarnos en las partes más creativas de nuestro trabajo, creamos una suite de bots más pequeños que nos ayudan a realizar el trabajo sucio. Aquí hay algunos ejemplos:

• Sudowoodo automatiza el proceso de lanzamiento de Electron de principio a fin, desde el inicio de compilaciones hasta la carga de activos de lanzamiento en GitHub y npm.
• Trop automatiza el proceso de retroportar para Electron al intentar seleccionar parches a ramas de lanzamiento anteriores basadas en las etiquetas de PR de GitHub.
• Roller automatiza las actualizaciones rodantes de las dependencias de Chromium y Node.js de Electron.
• Cation es nuestro bot de verificación de estado para las PR de electron/electron.

¡En conjunto, nuestra pequeña familia de bots nos ha dado un gran impulso en la productividad de los desarrolladores!

¿Qué sigue?​

Al entrar en nuestra segunda década como proyecto, es posible que te preguntes: ¿qué sigue para Electron?

Vamos a mantenernos en sincronía con el ritmo de lanzamiento de Chromium, publicando nuevas versiones principales de Electron cada 8 semanas, manteniendo el framework actualizado con lo último y lo mejor de la plataforma web y Node.js mientras mantenemos la estabilidad y seguridad para aplicaciones de calidad empresarial.

Generalmente anunciamos noticias sobre próximas iniciativas cuando se vuelven concretas. ¡Si quieres estar al tanto de futuros lanzamientos, funciones y actualizaciones generales del proyecto, puedes leer nuestro blog y seguir nuestros perfiles en redes sociales (Twitter y Mastodon)!