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.

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​

• Chromium 120.0.6099.56
  • Neu in Chrome 119 und in DevTools 119
  • Neu in Chrome 120 und in DevTools 120
• Node 18.18.2
  • Anmerkungen zu Node 18.18.0
  • Anmerkungen zu Node 18.18.1
  • Anmerkungen zu Node 18.18.2
• V8 12.0

Neue Funktionen​

• ESM-Unterstützung aktiviert. #37535
  • Für weitere Details siehe die ESM-Dokumentation.
• 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.

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.

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!

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}`,
  },
});

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.

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!

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!

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​

• Chromium 118.0.5993.32
  • Neu in Chrome 118
  • Neu in DevTools 118
• Node.js 18.17.1
  • Node 18.17.1 Blogbeitrag
  • Node 18.17.0 Blogbeitrag
• V8 11.8

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.

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.

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.

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.

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​

• Chromium 116.0.5845.62
  • Neu in Chrome 116
  • Neu in DevTools 116
• Node.js 18.16.1
  • Node 18.16.1 Blogbeitrag
• V8 11.2

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.

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.

Electron 25.0.0 wurde veröffentlicht! Dieses Update enthält Erweiterungen zu Chromium 114, V8 11.4, und Node.js 18.15.0. Lesen Sie unten für weitere Details!

Das Electron Team freut sich die Veröffentlichung von Electron 25.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​

Highlights​

• Implemented net.fetch within Electron's net module, using Chromium's networking stack. This differs from Node's fetch(), which uses Node.js' HTTP stack. See #36733 and #36606.
• Added protocol.handle, which replaces and deprecates protocol.{register,intercept}{String,Buffer,Stream,Http,File}Protocol. #36674
• Extended support for Electron 22, in order to match Chromium and Microsoft's Windows 7/8/8.1 deprecation plan. See additional details at the end of this blog post.

Stack-Änderungen​

• Chromium 114
  • Neu in Chrome 114
  • Neu in Chrome 113
  • Neu in DevTools 114
  • Neu in DevTools 113
• Node.js 18.15.0
  • Node 18.15.0 Blogbeitrag
• V8 11.4

Breaking Changes​

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

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

Die neue Methode kann entweder ein neues Protokoll registrieren oder ein bestehendes Protokoll abfangen, und Antworten können von jedem Typ sein.

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

// Ersetzt mit
protocol.handle('some-protocol', () => {
  return new Response(
    Buffer.from('<h5>Response</h5>'), // Kann auch ein string oder ReadableStream sein.
    { headers: { 'content-type': 'text/html' } },
  );
});

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

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

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

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

Veraltet: BrowserWindow.setTrafficLightPosition(position)​

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

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

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

Veraltet: BrowserWindow.getTrafficLightPosition()​

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

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

// Ersetzt mit
const ret = win.getWindowButtonPosition();
if (ret === null) {
  // Keine eigene Position.
}

Neue Funktionen​

• net.fetch() hinzugefügt. #36733
  • net.fetch supports requests to file: URLs and custom protocols registered with protocol.register*Protocol. #36606
• Added BrowserWindow.set/getWindowButtonPosition APIs. #37094
• Added protocol.handle, replacing and deprecating protocol.{register,intercept}{String,Buffer,Stream,Http,File}Protocol. #36674
• Added a will-frame-navigate event to webContents and the <webview> tag, which fires whenever any frame within the frame hierarchy attempts to navigate. #34418
• Added initiator information to navigator events. This information allows distinguishing window.open from a parent frame causing a navigation, as opposed to a child-initiated navigation. #37085
• Added net.resolveHost that resolves hosts using defaultSession object. #38152
• Neues 'did-resign-active' Event zu app hinzugefügt. #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
• Added thermal management information to powerMonitor. #38028
• Allows an absolute path to be passed to the session.fromPath() API. #37604
• Exposes the audio-state-changed event on webContents. #37366

22.x.y Support fortgesetzt​

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. Das Supportdatum vom Oktober folgt den erweiterten Supportdaten sowohl von Chromium als auch von Microsoft. Am 11. Oktober wird das Electron-Team die Unterstützung auf die letzten drei stabilen Hauptversionen zurückstellen, die Windows 7/8/8.1 nicht mehr unterstützen.

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.

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

Das Electron-Team freut sich über die Veröffentlichung von Electron 24.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.

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​

• Chromium 112.0.5615.49
  • Neu in Chrome 112
  • Neu in Chrome 111
  • Neu in DevTools 112
  • Neu in DevTools 111
• Node.js 18.14.0
  • Node 18.14.0 Blogbeitrag
• V8 11.2

Breaking Changes​

API geändert: 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 }
});

Neue Funktionen​

• 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

Ende der Unterstützung für 21.x.y​

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

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.

Sie finden die öffentliche Timeline von Electron hier.

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

Der erste Commit in das electron/electron Repository war am 13. März 2013¹.

10 Jahre und 27.147 weitere Commits von 1192 individuellen Mitwirkenden später, Electron ist heute zu einem der beliebtesten Frameworks für das Erstellen von Desktop-Anwendungen geworden. Dieser Meilenstein ist die perfekte Gelegenheit, um unsere bisherige Reise zu feiern und zu reflektieren, und mitzuteilen, was wir auf dem Weg gelernt haben.

Wir wären heute nicht hier ohne alle, die ihre Zeit und Mühe geopfert haben, um das Projekt zu unterstützen. Obwohl Quellcode-Commits immer die sichtbarsten Beiträge sind, müssen wir auch die Anstrengungen der Leute anerkennen, die Fehler melden, userland-Module warten, Dokumentation und Übersetzungen bereitstellen und an der Electron Community im gesamten Cyberspace teilnehmen. Jeder Beitrag ist für uns als Betreiber von unschätzbarem Wert.

Bevor wir mit dem Rest des Blog-Beitrags fortfahren: Vielen Dank. ❤️

Wie sind wir zu diesem Punkt gekommen?​

Atom Shell wurde als Gerüst für GitHubs Atom-Editorgebaut, der im April 2014 in die öffentliche Beta startete. Es wurde von Grund auf als Alternative zu den webbasierten Desktop-Frameworks gebaut, die zu dieser Zeit verfügbar waren (node-webkit und Chromium Embedded Framework). Es hatte eine Killer-Funktion: Einbetten von Node.js und Chromium, um eine leistungsfähige Desktop-Laufzeit für Web- Technologien zu bieten.

Innerhalb eines Jahres begann Atom Shell ein immenses Wachstum der Fähigkeiten und Popularität zu sehen. Große Firmen, Startups und einzelne Entwickler hatten gleichermaßen damit begonnen, Apps damit zu bauen (einige frühe Anwender waren Slack, GitKraken, und WebTorrent), und das Projekt wurde treffend in Electron umbenannt.

Von da an startete Electron voll durch und hielt nie auf. Hier ist ein Blick auf unsere wöchentliche Download-Anzahl über die Zeit, dank npmtrends.com:

Electron v1 wurde 2016 veröffentlicht und versprach eine höhere API-Stabilität und bessere Dokumentation und Werkzeuge. Electron v2 wurde 2018 veröffentlicht und führte semantische Versionierung ein, was es den Entwicklern von Electron einfacher macht, den Release-Zyklus zu verfolgen.

Mit Electron v6 haben wir auf eine reguläre 12-wöchige große Release-Kadenz umgeschaltet, um der Chromium-Kadenz zu folgen. Diese Entscheidung war ein Mentalitätswandel für das Projekt und hat "die aktuellste Chromium-Version zu haben" von einem Nice-to-have zu einer Priorität gemacht. Dies hat die Menge an technischer Schulden zwischen den Upgrades reduziert und macht es uns einfacher, Electron aktualisiert und sicher zu halten.

Seitdem sind wir eine gut geölte Maschine und veröffentlichen eine neue Elektro-Version am selben Tag wie jede stabile Version von Chromium. Als Chromium 2021 seinen Veröffentlichungszyklus auf 4 Wochen beschleunigte, konnten wir entspannt darauf reagieren und unseren Veröffentlichungsrhythmus entsprechend auf 8 Wochen erhöhen.

Wir sind nun bei Electron v23 (und es geht weiter) und sind weiterhin bestrebt, die beste Laufzeitumgebung für die Erstellung plattformübergreifender Desktop-Anwendungen zu entwickeln. Trotz des Booms von JavaScript-Entwicklerwerkzeugen in den letzten Jahren ist Electron ein stabiler und erprobter Eckpfeiler im Bereich der Desktop-Anwendungs-Frameworks geblieben. Heutzutage sind Electron-Apps allgegenwärtig: Du kannst mit Visual Studio Code programmieren, mit Figma designen, mit Slack kommunizieren und mit Notion Notizen machen (unter vielen anderen Anwendungsfällen). Wir sind unglaublich stolz auf diese Leistung und dankbar für alle, die dies möglich gemacht haben.

Was haben wir auf dem Weg gelernt?​

Der Weg zur Dekaden-Marke war lang und gewunden. Hier sind ein Paar der Kernelemente, die uns geholfen haben, ein solch großes Open-Source Projekt am Leben zu erhalten.

Skalierung verteilter Entscheidungsfindung mit einem Governance-Modell​

Eine Herausforderung, die wir bewältigen mussten, war, die langfristige Richtung des Projekts zu bewältigen, nachdem Electron zum ersten Mal in der Popularität explodierte. Wie gehen wir damit um, ein Team von ein paar Dutzend Ingenieuren zu sein, die über Firmen, Länder und Zeitzonen verteilt arbeiten?

In den Anfangstagen verließ sich die Gruppe der Electron-Maintainer auf informelle Koordination, die für kleinere Projekte schnell und unkompliziert ist, aber nicht auf breitere Zusammenarbeit skaliert. 2019 wechselten wir zu einem Governance-Modell, bei dem verschiedene Arbeitsgruppen formelle Verantwortungsbereiche haben. Dies war entscheidend, um Prozesse zu optimieren und Projektanteile spezifischen Maintainers zuzuweisen. Wofür ist jede Arbeitsgruppe (WG) heutzutage verantwortlich?

• Electron-Versionen herausbringen (Releases WG)
• Upgrade von Chromium und Node.js (Upgrades WG)
• Überwachung des öffentlichen API-Designs (API WG)
• Electron sicher halten (Sicherheit WG)
• Die Webseite am Laufen halten, Dokumentation und Bereitstellung von Werkzeugen (Ecosystem WG)
• Community und Firmenreichweite (Outreach WG)
• Community-Moderation (Community & Safety WG)
• Wartung unserer Build-Infrastruktur, Maintainer-Tools und Cloud-Services (Infrastructure WG)

Etwa zur gleichen Zeit, als wir zum Governance-Modell wechselten, übertrugen wir auch das Eigentum von Electron von GitHub zur OpenJS Foundation. Obwohl das ursprüngliche Kernteam heute noch bei Microsoft arbeitet, sind sie nur ein Teil einer größeren Gruppe von Mitwirkenden, die die Electron-Governance bilden.²

Obwohl dieses Modell nicht perfekt ist, hat es uns gut durch eine globale Pandemie und anhaltende makroökonomische Gegenwinde gebracht. Für die Zukunft planen wir, die Governance-Charta zu überarbeiten, um uns durch das zweite Jahrzehnt von Electron zu führen.

Community​

Der Community-Teil von Open Source ist schwierig, besonders wenn dein Outreach-Team aus einem Dutzend Ingenieuren in einem Trenchcoat besteht, auf dem "Community Manager" steht. Das bedeutet jedoch, dass wir als großes Open-Source-Projekt viele Nutzer haben, und ihre Energie für Electron zu nutzen, um ein Userland-Ökosystem aufzubauen, ist ein entscheidender Teil, um die Gesundheit des Projekts zu erhalten.

Was haben wir unternommen, um unsere Präsenz in der Community zu entwickeln?

Virtuelle Community aufbauen​

• Im Jahr 2020 starteten wir unseren Community-Discord-Server. Zuvor hatten wir einen Bereich im Forum von Atom, aber wir entschieden uns für eine informellere Messaging-Plattform, um einen Raum für Diskussionen zwischen Maintainern und Electron-Entwicklern sowie für allgemeine Debugging-Hilfe zu schaffen.
• This group has been instrumental in Electron growth in users from China’s booming tech scene, providing a space for them to collaborate on ideas and discuss Electron outside of our English-language spaces. We’d also like to thank cnpm for their work in supporting Electron’s nightly releases in their Chinese mirror for npm.

Participating in high-visibility open source programs​

• We have been celebrating Hacktoberfest every year since 2019. Hacktoberfest is yearly celebration of open source organized by DigitalOcean, and we get dozens of enthusiastic contributors every year looking to make their mark on open source software.
• In 2020, we participated in the initial iteration of Google Season of Docs, where we worked with @bandantonio to rework Electron’s new user tutorial flow.
• In 2022, we mentored a Google Summer of Code student for the first time. @aryanshridhar did some awesome work to refactor Electron Fiddle's core version loading logic and migrate its bundler to webpack.

Automatisieren Sie all die Dinge!​

Today, Electron governance has about 30 active maintainers. Less than half of us are full-time contributors, which means that there’s a lot of work to go around. What’s our trick to keeping everything running smoothly? Our motto is that computers are cheap, and human time is expensive. In typical engineer fashion, we’ve developed a suite of automated support tooling to make our lives easier.

Nicht Goma​

The core Electron codebase is a behemoth of C++ code, and build times have always been a limiting factor in how fast we can ship bug fixes and new features. In 2020, we deployed Not Goma, a custom Electron-specific backend for Google’s Goma distributed compiler service. Not Goma processes compilation requests from authorized user’s machines and distributes the process across hundreds of cores in the backend. It also caches the compilation result so that someone else compiling the same files will only need to download the pre-compiled result.

Since launching Not Goma, compilation times for maintainers have decreased from the scale of hours to minutes. A stable internet connection became the minimum requirement for contributors to compile Electron!

Kontinuierliche Faktor-Authentifizierung​

Continuous Factor Authentication (CFA) is a layer of automation around npm’s two-factor authentication (2FA) system that we combine with semantic-release to manage secure and automated releases of our various @electron/ npm packages.

While semantic-release already automates the npm package publishing process, it requires turning off two-factor authentication or passing in a secret token that bypasses this restriction.

We built CFA to deliver a time-based one-time password (TOTP) for npm 2FA to arbitrary CI jobs, allowing us to harness the automation of semantic-release while keeping the additional security of two-factor authentication.

We use CFA with a Slack integration front-end, allowing maintainers to validate package publishing from any device they have Slack on, as long as they have their TOTP generator handy.

Sheriff​

Sheriff ist ein Open-Source-Werkzeug, das wir geschrieben haben, um die Verwaltung von Berechtigungen in GitHub, Slack und Google Workspace zu automatisieren.

Sheriff’s key value proposition is that permission management should be a transparent process. It uses a single YAML config file that designates permissions across all the above listed services. With Sheriff, getting collaborator status on a repo or creating a new mailing list is as easy as getting a PR approved and merged.

Sheriff also has an audit log that posts to Slack, warning admins when suspicious activity occurs anywhere in the Electron organization.

…und alle unsere GitHub Bots​

GitHub is a platform with rich API extensibility and a first-party bot application framework called Probot. To help us focus on the more creative parts of our job, we built out a suite of smaller bots that help do the dirty work for us. Here are a few examples:

• Sudowoodo automates the Electron release process from start to finish, from kicking off builds to uploading the release assets to GitHub and npm.
• Trop automates the backporting process for Electron by attempting to cherry-pick patches to previous release branches based on GitHub PR labels.
• Roller automates rolling upgrades of Electron’s Chromium and Node.js dependencies.
• Cation ist unser Statusprüfbot für electron/electron PRs.

Insgesamt hat uns unsere kleine Bot-Familie einen enormen Schub in der Entwicklungsproduktivität gebracht!

Was kommt als Nächstes?​

Wenn wir in unser zweites Jahrzehnt als ein Projekt kommen, könnten Sie fragen: Was ist das nächste für Electron?

We’re going to stay in sync with Chromium's release cadence, releasing new major versions of Electron every 8 weeks, keeping the framework updated with the latest and greatest from the web platform and Node.js while maintaining stability and security for enterprise-grade applications.

We generally announce news on upcoming initiatives when they become concrete. If you want to keep up with future releases, features, and general project updates, you can read our blog and follow our social media profiles (Twitter and Mastodon)!