Saltar al contenido principal

· 4 lectura mínima

¡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:

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.

info

Si esta es tu primera participación en Google Summer of Code o si eres nuevo en código abierto en general recomendamos leer la [Guía de colaboradores](https\://google. ithub.io/gsocguides/student/) como un primer paso antes de comprometerse con la comunidad.

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.

info

Nuestro interlocutor de Google Summer of Code 2022, @aryanshridhar, hizo un trabajo increíble! Si quieres ver en qué trabajó Aryan durante su verano con Electron, puedes leer su informe en [2022 GSoC program archives](https\://summerofcode. ithgoogle.com/archive/2022/organizations/electron).

¿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

· 4 lectura mínima

¡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

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.

E29 (Feb'24)E30 (Apr'24)E31 (Jun'24)
29.x.y30.x.y31.x.y
28.x.y29.x.y30.x.y
27.x.y28.x.y29.x.y

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.

· 3 lectura mínima

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.
info

For the RFC to become Active, the PR must be approved by at least 2 API Working Group members. Before merging, the RFC should be presented synchronously and accepted unanimously by a quorum of at least two-thirds of the WG members. If consensus is reached, a one-month final comment period will be triggered, after which the PR will be merged.

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!

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:

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:

· 4 lectura mínima

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.

· 3 lectura mínima

¡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

Nuevas características

  • Enabled ESM support. #37535
  • 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.

E28 (Dic'23)E29 (Feb'24)E30 (Apr'24)
28.x.y29.x.y30.x.y
27.x.y28.x.y29.x.y
26.x.y27.x.y28.x.y

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.

· 6 lectura mínima

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!
Thank you!

🙇 Gran gracias a mahnunchik por las contribuciones tanto para el editor GCS como para soporte ESM en configuraciones de Forge!

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}`,
},
});
Leer más

📦 ¿Quieres aprender más? Para obtener una guía detallada, consulte la documentación de actualización automática de Forge.

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/.
Buscando estrellas

⭐ Durante este proceso, también tomamos accidentalmente el repositorio electron/packager privado, que tiene el desafortunado efecto secundario de borrar nuestro contador de estrellas de GitHub (más de 9000 antes de la borrada). Si eres un usuario activo del paquete, apreciaríamos una ⭐ Estrella ⭐!

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!

· 2 lectura mínima

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!

· 4 lectura mínima

¡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

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.

E27 (Oct'23)E28 (Dic'23)E29 (Feb'24)
27.x.y28.x.y29.x.y
26.x.y27.x.y28.x.y
25.x.y26.x.y27.x.y

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.

· 5 lectura mínima

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.

The sandbox makes that scenario a lot less scary: A process inside gets to freely use CPU cycles and memory — that’s it. Processes cannot write to disk or display their own windows. In the case of our libwep bug, the sandbox makes sure that an attacker cannot install or run malware. In fact, in the case of the original Pegasus attack on the employee’s iPhone, the attack specifically targeted a non-sandboxed image process to gain access to the phone, first breaking out of the boundaries of the normally sandboxed iMessage. When a CVE like the one in this example is announced, you still have to upgrade your Electron apps to a secure version — but in the meantime, the amount of damage an attacker can do is limited dramatically.

Migrating a vanilla Electron application from sandbox: false to sandbox: true is an undertaking. I know, because even though I have personally written the first draft of the Electron Security Guidelines, I have not managed to migrate one of my own apps to use it. That changed this weekend, and I recommend that you change it, too.

Don’t be scared by the number of line changes, most of it is in &lt;code&gt;package-lock.json&lt;/code&gt;

There are two things you need to tackle:

  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.

· 3 lectura mínima

¡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

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.

E26 (Aug'23)E27 (Oct'23)E28 (Jan'24)
26.x.y27.x.y28.x.y
25.x.y26.x.y27.x.y
24.x.y25.x.y26.x.y
22.x.y

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.