Zum Hauptteil springen

· Die Lesezeit beträgt 4 min

We are excited to announce that Electron has been accepted as a mentoring organization for the 20th edition of Google Summer of Code (GSoC) 2024! Google Summer of Code is a global program focused on bringing new contributors into open source software development.

For more program details, check out Google’s Summer of Code homepage.

About us

Electron is a JavaScript framework for building cross-platform desktop applications using web technologies. The core Electron framework is a compiled binary executable built with Chromium and Node.js, and is mostly written in C++.

Outside of Electron core, we also work on a variety of projects to help sustain the Electron organization, such as:

As a Summer of Code contributor, you would be collaborating with some of Electron’s core contributors on one of many projects under the github.com/electron umbrella.

Before applying

If you aren’t very familiar with Electron, we would recommend you start by reading the documentation and trying out examples in Electron Fiddle.

To learn more about Electron app distribution, you can also play around with Electron Forge by creating a sample application:

npm init electron-app@latest my-app

After familiarizing yourself with the code a bit, come join the conversation on the Electron Discord server.

info

If this is your first time participating in Google Summer of Code or if you’re new to open source in general, we recommend reading Google’s Contributor Guide as a first step before engaging with the community.

Drafting your proposal

Interested in collaborating with Electron? First, check out the seven project idea drafts that we have prepared. Alle aufgeführten Ideen sind derzeit offen für Vorschläge.

Have a different idea you’d like us to consider? We’re also open to accepting new ideas that are not on the proposed project list, but make sure your approach is thoroughly outlined and detailed. When in doubt, we recommend sticking with our listed ideas.

Ihre Bewerbung sollte beinhalten:

  • Your proposal: a written document that describes in detail what you plan to achieve over the course of the summer.
  • Dein Hintergrund als Entwickler. If you have a resume, please include a copy. Otherwise, tell us about your past technical experience.
    • Lack of experience in certain areas won’t disqualify you, but it will help our mentors work out a plan to best support you and make sure your summer project is successful.

A detailed guide of what to submit as part of your Electron application is here. Submit proposals directly to the Google Summer of Code portal. Note that proposals emailed to the Electron team rather than submitted through the application portal will not be considered as a final submission.

If you want more guidance on your proposal or are unsure of what to include, we also recommend that you follow the official Google Summer of Code proposal writing advice here.

Applications open on March 18th, 2024 and close on April 2nd, 2024.

info

Our 2022 Google Summer of Code intern, @aryanshridhar, did an amazing job! If you want to see what Aryan worked on during his summer with Electron, you can read his report in the 2022 GSoC program archives.

Fragen?

If you have questions we didn’t address in the blog post or inquiries for your proposal draft, please send us an email at summer-of-code@electronjs.org or check GSoC FAQ!

Ressourcen

· Die Lesezeit beträgt 4 min

Electron 29.0.0 wurde veröffentlicht! It includes upgrades to Chromium 122.0.6261.39, V8 12.2, and Node.js 20.9.0.


Das Electron-Team freut sich, die Veröffentlichung von Electron 29.0.0 ankündigen zu können! Sie können es mit npm über npm electron@latest installieren oder von unserer Releases-Website herunterladen. Lesen Sie weiter für Details zu dieser Version.

Wenn Sie Feedback haben, teilen Sie es uns bitte auf Twitter oder Mastodon mit oder treten Sie unserem Community-Discord bei! Bugs und Feature-Anfragen können im Issue-Tracker von Electron gemeldet werden.

Bemerkenswerte Änderungen

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-Änderungen

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.

Neue Funktionen

  • 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

Breaking Changes

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

Ende der Unterstützung für 26.x.y

Electron 26.x.y hat das Ende des Supports gemäß der Support-Richtlinie des Projekts erreicht. 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.

Sie können die öffentliche Zeitleiste von Electron hier finden.

Weitere Informationen über zukünftige Änderungen können auf der Geplante Breaking Changes Seite gefunden werden.

· Die Lesezeit beträgt 3 min

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.

Wie funktioniert das?

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:

· Die Lesezeit beträgt 4 min

Earlier today, the Electron team was alerted to several public CVEs recently filed against several notable Electron apps. The CVEs are related to two of Electron’s fuses - runAsNode and enableNodeCliInspectArguments - and incorrectly claim that a remote attacker is able to execute arbitrary code via these components if they have not been actively disabled.

We do not believe that these CVEs were filed in good faith. First of all, the statement is incorrect - the configuration does not enable remote code execution. Secondly, companies called out in these CVEs have not been notified despite having bug bounty programs. Lastly, while we do believe that disabling the components in question enhances app security, we do not believe that the CVEs have been filed with the correct severity. “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.

Mitigation

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. Stattdessen empfehlen wir, dass Sie Utility Processes verwenden, welche für viele Anwendungsfälle funktionieren, in denen Sie einen eigenständigen Node.js-Prozess (wie einen Sqlite Server-Prozess oder ähnliche Szenarien) benötigen.

Weitere Informationen über Best Practices für die Sicherheit, die wir für Electron-Anwendungen empfehlen, können Sie in unserer Sicherheitscheckliste finden.

· Die Lesezeit beträgt 3 min

Electron 28.0.0 wurde veröffentlicht! Es enthält Upgrades auf Chromium 120.0.6099.56, V8 12.0, und Node.js 18.18.2.


Das Electron-Team freut sich, die Veröffentlichung von Electron 28.0.0 ankündigen zu können! Sie können es mit npm über npm electron@latest installieren oder von unserer Releases-Website herunterladen. Lesen Sie weiter für Details zu dieser Version.

Wenn Sie Feedback haben, teilen Sie es uns bitte auf Twitter oder Mastodon mit oder treten Sie unserem Community-Discord bei! Bugs und Feature-Anfragen können im Issue-Tracker von Electron gemeldet werden.

Bemerkenswerte Änderungen

Highlights

  • Unterstützung für ECMAScript Module oder ESM Implementiert (Was sind ECMAScript Module? hier mehr erfahren). Dies beinhaltet die Unterstützung für ESM in Electron selbst sowie Bereiche wie die "UtilityProcess"-API-Einstiegspunkte. Siehe unsere ESM-Dokumentation für weitere Details.
  • Neben ESM-Unterstützung in Electron selbst unterstützt Electron Forge auch die Verwendung von ESM zum Paketieren, Erstellen und Entwickeln von Electron-Anwendungen. Sie können diese Unterstützung in Forge v7.0.0 oder höher finden.

Stack-Änderungen

Neue Funktionen

  • ESM-Unterstützung aktiviert. #37535
  • ESM Einstiegspunkte zur "UtilityProcess" API hinzugefügt. #40047
  • Mehrere Eigenschaften dem display Objekt hinzugefügt, einschließlich detected, maximumCursorSize und nativeOrigin. #40554
  • Unterstützung für die Umgebungsvariable ELECTRON_OZONE_PLATFORM_HINT unter Linux hinzugefügt. #39792

Breaking Changes

Geändertes Verhalten: WebContents.backgroundThrottling auf false gesetzt wirkt sich auf alle WebContents im Host BrowserWindow aus

"WebContents.backgroundThrottling" auf "false" gesetzt deaktiviert Frame Throttling im "BrowserWindow" für alle von diesem angezeigten "WebContents".

Entfernt: BrowserWindow.setTrafficLightPosition(position)

BrowserWindow.setTrafficLightPosition(position) wurde entfernt, die BrowserWindow.setWindowButtonPosition(position) API sollte stattdessen verwendet werden, welche null anstelle von { x: 0, y: 0 } akzeptiert um die Position auf Systemstandard zurückzusetzen.

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

// Ersetzen mit
win.setWindowButtonPosition({ x: 10, y: 10 });
win.setWindowButtonPosition(null);

Entfernt: BrowserWindow.getTrafficLightPosition()

BrowserWindow.getTrafficLightPosition() wurde entfernt, die BrowserWindow.getWindowButtonPosition() API sollte stattdessen verwendet werden, welche null anstelle von { x: 0, y: 0 } zurückgibt, wenn keine benutzerdefinierte Position vorhanden ist.

// Entfernt in Electron 28
const pos = win.getTrafficLightPosition();
if (pos. === 0 && pos.y === 0) {
// Keine benutzerdefinierte Position.
}

// Ersetzen mit
const ret = win. etWindowButtonPosition();
if (ret === null) {
// Keine benutzerdefinierte Position.
}

Entfernt: ipcRenderer.sendTo()

Die API ipcRenderer.sendTo() wurde entfernt. Sie sollte durch das Einrichten eines MessageChannel zwischen den Renderern ersetzt werden.

Die senderId und senderIsMainFrame Eigenschaften von IpcRendererEvent wurden ebenfalls entfernt.

Entfernt: app.runningUnderRosettaTranslation

Die Eigenschaft app.runningUnderRosettaTranslation wurde entfernt. Verwende stattdessen app.runningUnderARM64Translation.

// Entfernt
console.log(app.runningUnderRosettaTranslation)
// Ersetzen durch
console.log(app.runningUnderARM64Translation);

Ende der Unterstützung für 25.x.y

Electron 25.x.y hat das Ende des Supports gemäß der Support-Richtlinie des Projekts erreicht. Developers and applications are encouraged to upgrade to a newer version of Electron.

E28 (Dec'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.

Sie können die öffentliche Zeitleiste von Electron hier finden.

Weitere Informationen über zukünftige Änderungen können auf der Geplante Breaking Changes Seite gefunden werden.

· Die Lesezeit beträgt 5 min

Reflecting on the improvements and changes in Electron's developer ecosystem in 2023.


In the past few months, we've been cooking up some changes across the Electron ecosystem to supercharge the developer experience for Electron apps! Here’s a swift rundown of the latest additions straight from Electron HQ.

Electron Forge 7 and beyond

Electron Forge 7 — the newest major version of our all-in-one tool for packaging and distributing Electron applications — is now available.

While Forge 6 was a complete rewrite from v5, v7 is smaller in scope but still contains a few breaking changes. Going forward, we will continue to publish major versions of Forge as breaking changes need to be made.

For more details, see the full Forge v7.0.0 changelog on GitHub.

Wichtige Änderungen

  • Switched to notarytool for macOS notarization: As of 2023-11-01, Apple sunset the legacy altool for macOS notarization, and this release removes it from Electron Forge entirely.
  • Minimum Node.js increased to v16.4.0: With this release, we’ve set the minimum required Node.js version to 16.4.0.
  • Dropped support for electron-prebuilt and electron-prebuilt-compile: electron-prebuilt was the original name for Electron’s npm module, but was replaced by electron in v1.3.1. electron-prebuilt-compile was an alternative to that binary that came with enhanced DX features, but was eventually abandoned as a project.

Highlights

  • Google Cloud Storage publisher: As part of our push to better support static auto updating, Electron Forge now supports publishing directly to Google Cloud Storage!
  • ESM forge.config.js support: Electron Forge now supports ESM forge.config.js files. (P.S. Look forward to ESM entrypoint support in Electron 28.)
  • Makers now run in parallel: In Electron Forge 6, Makers ran sequentially for ✨ legacy ✨ reasons. Since then, we’ve tested out parallelization for the Make step with no adverse side effects, so you should see a speed-up when building multiple targets for the same platform!
Thank you!

🙇 Big thanks to mahnunchik for the contributions for both the GCS Publisher and ESM support in Forge configurations!

Better static storage auto updates

Squirrel.Windows and Squirrel.Mac are platform-specific updater technologies that back Electron’s built-in autoUpdater module. Both projects support auto updates via two methods:

  • A Squirrel-compatible update server
  • A manifest URL hosted on a static storage provider (e.g. AWS, Google Cloud Platform, Microsoft Azure, etc.)

The update server method has traditionally been the recommended approach for Electron apps (and provides additional customization of update logic), but it has a major downside—it requires apps to maintain their own server instance if they are closed-source.

On the other hand, the static storage method has always been possible, but was undocumented within Electron and poorly supported across Electron tooling packages.

With some great work from @MarshallOfSound, the update story for serverless automatic app updates has been drastically streamlined:

  • Electron Forge’s Zip and Squirrel.Windows makers can now be configured to output autoUpdater-compatible update manifests.
  • A new major version of update-electron-app (v2.0.0) can now read these generated manifests as an alternative to the update.electronjs.org server.

Once your Makers and Publishers are configured to upload update manifests to cloud file storage, you can enable auto updates with only a few lines of configuration:

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

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

📦 Want to learn more? For a detailed guide, see Forge’s auto update documentation.

The @electron/ extended universe

When Electron first started, the community published many packages to enhance the experience of developing, packaging, and distributing Electron apps. Over time, many of these packages were incorporated into Electron’s GitHub organization, with the core team taking on the maintenance burden.

In 2022, we began unifying all these first-party tools under the @electron/ namespace on npm. This change means that packages that used to be electron-foo are now @electron/foo on npm, and repositories that used to be named electron/electron-foo are now electron/foo on GitHub. These changes help clearly delineate first-party projects from userland projects. This includes many commonly used packages, such as:

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

Going forward, all first-party packages we release will also be in the @electron/ namespace. There are two exceptions to this rule:

  • Electron core will continue to be published under the electron package.
  • Electron Forge will continue to publish all of its monorepo packages under the @electron-forge/ namespace.
Star seeking

⭐ During this process, we also accidentally took the electron/packager repository private, which has the unfortunate side effect of erasing our GitHub star count (over 9000 before the erasure). If you are an active user of Packager, we’d appreciate a ⭐ Star ⭐!

Introducing @electron/windows-sign

Starting on 2023-06-01, industry standards began requiring keys for Windows code signing certificates to be stored on FIPS-compliant hardware.

In practice, this meant that code signing became a lot harder for apps that build and sign in CI environments, since many Electron tools take in a certificate file and password as config parameters and attempt to sign from there using hardcoded logic.

This situation has been a common pain point for Electron developers, which is why we have been working on a better solution that isolates Windows code signing into its own standalone step, similar to what @electron/osx-sign does on macOS.

In the future, we plan on fully integrating this package into the Electron Forge toolchain, but it currently lives on its own. The package is currently available for installation at npm install --save-dev @electron/windows-sign and can used programmatically or via CLI.

Please try it out and give us your feedback in the repo’s issue tracker!

What's next?

We'll be entering our annual December quiet period next month. While we do, we'll be thinking about how we can make the Electron development experience even better in 2024.

Is there anything you'd like to see us work on next? Gib uns Bescheid!

· Die Lesezeit beträgt 2 min

The Electron project will pause for the month of December 2023, then return to full speed in January 2024.

via GIPHY


Was im Dezember gleich sein wird

  1. Bei Bedarf werden Tages- und andere wichtige sicherheitsrelevante Veröffentlichungen veröffentlicht. Security incidents should be reported via SECURITY.md.
  2. Code of Conduct reports and moderation will continue.

Was wird im Dezember anders sein

  1. Electron 28.0.0 will be released on December 5th. After Electron 28, there will be no new Stable releases in December.
  2. No Nightly and Alpha releases for the last two weeks of December.
  3. Mit wenigen Ausnahmen, keine Pull-Request Reviews oder Merges.
  4. Keine Updates für Issue-Tracker auf Repositories.
  5. Keine Discord Debugging-Hilfe von Betreuern.
  6. Keine Updates für Inhalte der sozialen Medien.

Going forward

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!

· Die Lesezeit beträgt 3 min

Electron 27.0.0 wurde veröffentlicht! Es enthält Upgrades auf Chromium 118.0.5993.32, V8 11.8 und Node.js 18.17.1.


Das Electron-Team freut sich über die Veröffentlichung von Electron 27.0.0! Sie können es mit npm über npm install electron@latest installieren oder von unserer Release-Website herunterladen. Lesen Sie weiter für Details zu dieser Version.

If you have any feedback, please share it with us on Twitter or Mastodon, or join our community Discord! Bugs und Feature-Requests können in Electrons Issue-Tracker gemeldet werden.

Bemerkenswerte Änderungen

Stack-Änderungen

Breaking Changes

Removed: macOS 10.13 / 10.14 support

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

Older versions of Electron will continue to run on these operating systems, but macOS 10.15 (Catalina) or later will be required to run Electron v27.0.0 and higher.

Veraltet: ipcRenderer.sendTo()

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

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

Removed: color scheme events in systemPreferences

The following systemPreferences events have been removed:

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

Use the new updated event on the nativeTheme module instead.

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

// Replace with
nativeTheme.on('updated', () => {
/* ... */
});

Entfernt: webContents.getPrinters

The webContents.getPrinters method has been removed. Verwende stattdessen webContents.getPrintersAsync.

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

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

Removed: systemPreferences.{get,set}AppLevelAppearance and systemPreferences.appLevelAppearance

The systemPreferences.getAppLevelAppearance and systemPreferences.setAppLevelAppearance methods have been removed, as well as the systemPreferences.appLevelAppearance property. Verwenden Sie stattdessen das nativeTheme Modul.

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

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

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

Removed: alternate-selected-control-text value for systemPreferences.getColor

The alternate-selected-control-text value for systemPreferences.getColor has been removed. Verwenden Sie stattdessen selected-content-background.

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

Neue Funktionen

  • Added app accessibility transparency settings api #39631
  • Added support for chrome.scripting extension APIs #39675
  • Enabled WaylandWindowDecorations by default #39644

Ende der Unterstützung für 24.x.y

Electron 24.x.y hat das Ende der Unterstützung gemäß der Unterstützungsrichtlinien des Projekts erreicht. Developers and applications are encouraged to upgrade to a newer version of Electron.

E27 (Okt'23)E28 (Dec'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

End of Extended Support for 22.x.y

Earlier this year, the Electron team extended Electron 22's planned end of life date from May 30, 2023 to October 10, 2023, in order to match Chrome's extended support for Windows 7/8/8.1 (see Farewell, Windows 7/8/8.1 for more details).

Electron 22.x.y has reached end-of-support as per the project's support policy and this support extension. This will drop support back to the latest three stable major versions, and will end official support for 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.

Sie finden die öffentliche Timeline von Electron hier.

Weitere Informationen über zukünftige Änderungen finden Sie auf der geplante Änderungen Seite.

· Die Lesezeit beträgt 4 min

It’s been more than a week since CVE-2023-4863: Heap buffer overflow in WebP was made public, leading to a flurry of new releases of software rendering webp images: macOS, iOS, Chrome, Firefox, and various Linux distributions all received updates. This followed investigations by Citizen Lab, discovering that an iPhone used by a “Washington DC-based civil society organization” was under attack using a zero-click exploit within iMessage.

Electron, too, spun into action and released new versions the same day: If your app renders any user-provided content, you should update your version of Electron - v27.0.0-beta.2, v26.2.1, v25.8.1, v24.8.3, and v22.3.24 all contain a fixed version of libwebp, the library responsible for rendering webp images.

Now that we are all freshly aware that an interaction as innocent as “rendering an image” is a potentially dangerous activity, we want to use this opportunity to remind everyone that Electron comes with a process sandbox that will limit the blast radius of the next big attack — whatever it may be.

The sandbox was available ever since Electron v1 and enabled by default in v20, but we know that many apps (especially those that have been around for a while) may have a sandbox: false somewhere in their code – or a nodeIntegration: true, which equally disables the sandbox when there is no explicit sandbox setting. That’s understandable: If you’ve been with us for a long time, you probably enjoyed the power of throwing a require("child_process") or require("fs") into the same code that runs your HTML/CSS.

Before we talk about how you migrate to the sandbox, let’s first discuss why you want it.

The sandbox puts a hard cage around all renderer processes, ensuring that no matter what happens inside, code is executed inside a restricted environment. As a concept, it's a lot older than Chromium, and provided as a feature by all major operating systems. Electron's and Chromium's sandbox build on top of these system features. Even if you never display user-generated content, you should consider the possibility that your renderer might get compromised: Scenarios as sophisticated as supply chain attacks and as simple as little bugs can lead to your renderer doing things you didn't fully intend for it to do.

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.

· Die Lesezeit beträgt 2 min

Electron 26.0.0 wurde veröffentlicht! Dieses Update enthält Erweiterungen zu Chromium 116.0.5845.62, V8 11.2, und Node.js 18.16.1. Lesen Sie unten für weitere Details!


Das Electron Team freut sich die Veröffentlichung von Electron 26.0.0 anzukündigen! Sie können es mit npm über npm install electron@latest installieren oder von unserer Release-Website herunterladen. Lesen Sie weiter für Details zu dieser Version.

Wenn du ein Feedback hast, teile es bitte mit uns auf Twitter, oder trete unserer Community Discord bei! Bugs und Feature-Requests können in Electrons Issue-Tracker gemeldet werden.

Bemerkenswerte Änderungen

Stack-Änderungen

Breaking Changes

Veraltet: webContents.getPrinters

Die webContents.getPrinters Methode wurde veraltet. Verwende stattdessen webContents.getPrintersAsync.

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

// Veraltet
console.log(w.webContents.getPrinters());
// Ersetzt mit
w.webContents.getPrintersAsync().then((printers) => {
console.log(printers);
});

Veraltet: systemPreferences.{get,set}AppLevelAppearance und systemPreferences.appLevelAppearance

Die systemPreferences.getAppLevelAppearance und systemPreferences.setAppLevelAppearance Methoden sowie die systemPreferences.appLevelAppearance Eigenschaft wurden veraltet. Verwenden Sie stattdessen das nativeTheme Modul.

// Veraltet
systemPreferences.getAppLevelAppearance();
// Ersetzt mit
nativeTheme.shouldUseDarkColors;

// Veraltet
systemPreferences.appLevelAppearance;
// Ersetzt mit
nativeTheme.shouldUseDarkColors;

// Veraltet
systemPreferences.setAppLevelAppearance('dark');
// Ersetzt mit
nativeTheme.themeSource = 'dark';

Veraltet: alternate-selected-control-text Wert für systemPreferences.getColor

Der alternate-selected-control-text Wert für systemPreferences.getColor wurde veraltet. Verwenden Sie stattdessen selected-content-background.

// Veraltet
systemPreferences.getColor('alternate-selected-control-text');
// Ersetzt mit
systemPreferences.getColor('selected-content-background');

Neue Funktionen

  • safeStorage.setUsePlainTextEncryption und safeStorage.getSelectedStorageBackend API hinzugefügt. #39107
  • safeStorage.setUsePlainTextEncryption und safeStorage.getSelectedStorageBackend API hinzugefügt. #39155
  • senderIsMainFrame zu Nachrichten hinzugefügt, die über ipcRenderer.sendTo() gesendet wurden. #39206
  • Unterstützung für das Markieren eines Menüs als initiierte Tastatur hinzugefügt. #38954

Ende der Unterstützung für 23.x.y

Electron 23.x.y hat das Ende der Unterstützung gemäß der Unterstützungsrichtlinien des Projekts erreicht. Developers and applications are encouraged to upgrade to a newer version of Electron.

E26 (Aug'23)E27 (Okt'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.

Sie finden die öffentliche Timeline von Electron hier.

Weitere Informationen über zukünftige Änderungen finden Sie auf der geplante Änderungen Seite.