メインコンテンツへ飛ぶ

· 読むのにかかる時間 1 分

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. 掲載されているアイデアは、すべて企画のために現在公開中のものです。

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.

応募には以下のものがあるとよいでしょう。

  • Your proposal: a written document that describes in detail what you plan to achieve over the course of the summer.
  • 開発者としての経歴。 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.

質問?

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!

リソース

· 読むのにかかる時間 1 分

Electron 29.0.0 がリリースされました! It includes upgrades to Chromium 122.0.6261.39, V8 12.2, and Node.js 20.9.0.


Electron チームは、Electron 29.0.0 のリリース発表にワクワクしています! npm install electron@latest から npm でインストールするか、リリースウェブサイト からダウンロードできます。 このリリースの詳細は続きをご覧ください。

何かフィードバックがあれば、TwitterMastodon で共有したり、コミュニティの Discord に参加してみましょう! バグや機能の要望は Electron の Issue トラッカー で報告できます。

注目すべき変更

ハイライト

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

累積的変更

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.

新機能

  • 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

破壊的変更

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

26.x.y サポートの終了

プロジェクトの サポートポリシー に則り、Electron 26.x.y はサポート終了を迎えました。 開発者とアプリケーションは新しいバージョンの 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

次回予告

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.

短期的には、Chromium、Node、V8 といった Electron を構成する主要コンポーネントの開発に遅れないでチームが注力し続けるでしょう。

Electron の公開タイムラインはこちらで ご覧いただけます。

今後の変更についての詳細は、予定されている破壊的変更 のページをご覧ください。

· 読むのにかかる時間 1 分

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.

どのように動作するのですか?

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:

· 読むのにかかる時間 1 分

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.

緩和策

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. Instead, we recommend that you use Utility Processes, which work for many use cases where you need a standalone Node.js process (like a Sqlite server process or similar scenarios).

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

· 読むのにかかる時間 1 分

Electron 28.0.0 がリリースされました! これには Chromium 120.0.6099.56、V8 12.0、Node.js 18.18.2 へのアップグレードが含まれています。


Electron チームは、Electron 28.0.0 のリリース発表にワクワクしています! npm install electron@latest から npm でインストールするか、リリースウェブサイト からダウンロードできます。 このリリースの詳細は続きをご覧ください。

何かフィードバックがあれば、TwitterMastodon で共有したり、コミュニティの Discord に参加してみましょう! バグや機能の要望は Electron の Issue トラッカー で報告できます。

注目すべき変更

ハイライト

  • ECMAScript モジュール、略して ESM のサポートを実装しました (ECMAScript モジュールとは何かですって? こちらで詳しく学べます。 これは Electron での ESM サポートだけでなく、UtilityProcess API のエントリポイントなどの領域も含まれます。 詳細については 私たちの ESM の ドキュメント をご参照ください。
  • 加えて Electron Forge は、Electron 自体での ESM サポートだけでなく Electron アプリケーションのパッケージ化、ビルド、開発においても ESM をサポートしています。 このサポートは Forge v7.0.0 以降となります。

累積的変更

新機能

  • ESM サポートを有効化しました。 #37535
  • UtilityProcess API に ESM エントリポイントを追加しました。 #40047
  • display オブジェクトに、detectedmaximumCursorSizenativeOrigin を含むいくつかのプロパティを追加しました。 #40554
  • Linux で ELECTRON_OZONE_PLATFORM_HINT 環境変数のサポートを追加しました。 #39792

破壊的変更

動作変更:WebContents.backgroundThrottling を false にすると、ホストの WebContents 内のすべての BrowserWindow に影響します

WebContents.backgroundThrottling を false に設定すると、BrowserWindow によって表示されるすべての WebContents でのフレーム抑制が無効になります。

削除: BrowserWindow.setTrafficLightPosition(position)

BrowserWindow.setTrafficLightPosition(position) は削除されたので、代わりに BrowserWindow.setWindowButtonPosition(position) API を使用してください。こちらは、デフォルトの位置へリセットする際に { x: 0, y: 0 } ではなく null を受け取るようになっています。

// Electron 28 で非推奨
win.setTrafficLightPosition({ x: 10, y: 10 });
win.setTrafficLightPosition({ x: 0, y: 0 });

// こちらに置き換えてください
win.setWindowButtonPosition({ x: 10, y: 10 });
win.setWindowButtonPosition(null);

削除: BrowserWindow.getTrafficLightPosition()

BrowserWindow.getTrafficLightPosition() は削除されたので、代わりに BrowserWindow.getWindowButtonPosition() API を使用してください。こちらは、カスタム位置が無ければ { x: 0, y: 0 } ではなく null を返すようになっています。

// Electron 28 で削除
const pos = win.getTrafficLightPosition();
if (pos.x === 0 && pos.y === 0) {
// カスタム位置が無い時。
}

// こちらに置き換えてください
const ret = win.getWindowButtonPosition();
if (ret === null) {
// カスタム位置が無い時。
}

削除: ipcRenderer.sendTo()

ipcRenderer.sendTo() API は削除されました。 これはレンダラー間で MessageChannel を設置するように置き換える必要があります。

IpcRendererEventsenderIdsenderIsMainFrame のプロパティも削除されました。

削除: app.runningUnderRosettaTranslation

app.runningUnderRosettaTranslation プロパティは削除されました。 代わりに app.runningUnderARM64Translation を使用してください。

// 削除されました
console.log(app.runningUnderRosettaTranslation);
// こちらで置き換えてください
console.log(app.runningUnderARM64Translation);

25.x.y サポートの終了

プロジェクトの サポートポリシー に則り、Electron 25.x.y はサポート終了を迎えました。 開発者とアプリケーションは新しいバージョンの 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

次回予告

短期的には、Chromium、Node、V8 といった Electron を構成する主要コンポーネントの開発に遅れないでチームが注力し続けるでしょう。

Electron の公開タイムラインはこちらで ご覧いただけます。

今後の変更についての詳細は、予定されている破壊的変更 のページをご覧ください。

· 読むのにかかる時間 1 分

2023 年の Electron の開発者エコシステムの改善と変化を振り返ります。


過去数ヶ月で、Electron アプリの開発者体験を強化するために、Electron エコシステム全体でいくつかの変更を醸成してきました。 Electron HQ からの最新の追加の速報はこちらです。

Electron Forge 7 とその先

Electron Forge 7、Electron アプリケーションのパッケージ化と頒布のためのオールインワンツールの最新メジャーバージョンが利用できるようになりました。

Forge 6 は v5 からの完全な書き換えでした。v7 のスコープは小さいですが、いくつかの改善点が含まれています。 今後も、破壊的変更が必要になり次第、Forge のメジャーバージョンを発行していきます。

詳細については、GitHub 上の Forge v7.0.0 変更ログ をご覧ください。

破壊的変更

  • macOS の公証を notarytool に切り替えました: 2023-11-01 時点で、Apple は macOS の公証のための altool をレガシーとしました。今回のリリースでは Electron Forge からこれを完全に削除します。
  • 最小の Node.js を v16.4.0 に引き上げました: 今回のリリースでは、Node.js のバージョンの最小要件を 16.4.0 に設定しました。
  • electron-prebuiltelectron-prebuilt-compile のサポートを終了しました: electron-prebuilt は Electron の npm モジュールの元々の名前で, これは v1.3.1 で electron に置き換えられていました。 electron-prebuilt-compile はその DX 機能が強化された代替バイナリでしたが、最終的にプロジェクトとして放棄されました。

ハイライト

  • Google Cloud Storage パブリッシャー: Electron Forge は静的自動更新のサポートを強化する一環として、Google Cloud Storage への直接公開をサポートしました!
  • ESM の forge.config.js のサポート: Electron Forge は ESM の forge.config.js ファイルをサポートするようになりました。 (P.S. Electron 28 での ESM エントリポイントのサポートをご期待ください。)
  • Maker を並列実行するようになりました: Electron Forge 6 では、Maker は ✨ レガシー✨ な理由で直列実行していました。 それ以来、副作用のない Make ステップの並列化をテストしてきました。これで同一プラットフォーム向けに複数のターゲットをビルドするときの速度が向上しているとわかるでしょう!
ありがとうございます!

🙇 Forge の設定で GCS パブリッシャーと ESM の両方のサポートに貢献していただいた mahnunchik** さんに多大な感謝を送ります!

静的ストレージの自動更新の改善

Squirrel.Windows と Squirrel.Mac は、Electron に組み込まれた autoUpdater モジュールの土台となるプラットフォーム固有のアップデーター技術です。 両方のプロジェクトは次の 2 つの方法で自動更新をサポートしています。

  • Squirrel 互換のアップデートサーバー
  • 静的ストレージプロバイダ (AWS、Google Cloud Platform、Microsoft Azure など) でホストされているマニフェスト URL。

従来のアップデートサーバーの手法は Electron アプリに推奨されるアプローチ (かつ更新ロジックの追加カスタマイズを提供するもの) でしたが、これには大きな欠点があります。それは、アプリがクローズドソースの場合、独自のサーバーインスタンスをメンテナンスする必要があることです。

一方、静的ストレージの手法は常に可能でしたが、Electron 内で文書化されておらず、Electron のツールパッケージの間でサポートされていませんでした。

@MarshallOfSound さんの素晴らしい働きにより、サーバーレス自動アプリ更新のアップデートのシナリオが大幅に能率化されました。

  • Electron Forge の Zip と Squirrel.Windows メーカーは、autoUpdater 互換の更新マニフェストを出力する設定ができるようになりました。
  • update-electron-app の新しいメジャーバージョン (v2.0.0) で、これらの生成されたマニフェストを update.electronjs.org サーバーの代替として読み込めるようになりました。

メーカーとパブリッシャーが更新マニフェストをクラウドファイルストレージへアップロードするように設定すれば、以下の数行の設定で自動更新を有効化できます。

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

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

📦 もっと知りたいですか? 詳細なガイドにつきましては、Forge の自動更新のドキュメント をご参照ください。

@electron/ で拡張された世界

はじめに Electron が始動したとき、コミュニティは Electron アプリケーションの開発、パッケージ化、頒布の体験向上のために多くのパッケージを公開しました。 これらのパッケージの多くは Electron の GitHub Organization に組み込まれ、コアチームがそのメンテナンスを負担していました。

2022 年には、npm の @electron/ 名前空間の下で、これらのファーストパーティツールをすべて統一し始めました。 この変更により、以前の electron-foo パッケージは npm で @electron/foo になり、かつて electron/electron-foo という名前だったレポジトリは GitHub 上で electron/foo となりました。 これらの変更は、ユーザーランドとファーストパーティのプロジェクトを明確に分別するのに役立ちます。 これには以下のような、一般的に使用されているパッケージが多数含まれます。

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

今後リリースされるファーストパーティパッケージも、すべて @electron/ 名前空間になります。 このルールには 2 つの例外があります。

  • Electron のコアは electron パッケージの下で引き続き公開されます。
  • Electron Forge は @electron-forge/ 名前空間の下にその monorepo パッケージ全てを公開し続けます。
スターの落とし物

⭐ この過程で、私たちは誤って electron/packager リポジトリを非公開にしてしまいました。これにより、GitHub のスターの数を消えるという不幸な副作用がありました (消える前は 9000 以上でした)。 Packager をいつもご利用の方は、⭐ スター ⭐ していただけると幸いです!

@electron/windows-sign の紹介

2023-06-01 以降、業界標準は FIPS 準拠のハードウェアに格納される Windows のコード署名証明書の鍵を要求するようになりました。

実際には、CI 環境でビルドおよびサインインを行うアプリにとってのコード署名が非常に困難になりました。 多くの Electron ツールは、設定パラメータとして証明書ファイルとパスワードを取り込み、そこからハードコードされたロジックで署名しようとします。

この状況は Electron 開発者にとって共通の苦痛となっています。だからこそ、Windows のコード署名をスタンドアローンな手順へと分離する改善策に取り組んでいるのです。この手順は macOS で @electron/osx-sign が行うことに似ています。

将来的には、このパッケージを Electron Forge のツールチェーンに完全に統合する予定ですが、現在は独自のものになっています。 そのパッケージは現在 npm install --save-dev @electron/windows-sign でインストールでき、プログラムからまたは CLI 経由で利用できます。

レポジトリの Issue トラッカー にてぜひご意見をお寄せください!

次は何をするのでしょうか?

私たちは来月から、毎年 12 月の安息期に入る予定です。 私たちはその間、2024 年に Electron の開発体験をさらに向上させる方法について考えていることでしょう。

次に取り組んでほしいことがおありですか? ぜひお聞かせください!

· 読むのにかかる時間 1 分

Electron プロジェクトは 2023 年 12 月の 1 ヶ月間休止し、2024 年 1 月から全力に戻ります。

GIPHY より


12 月でも変わらないこと

  1. ゼロデイやその他の主要なセキュリティ関連のリリースは必要に応じて公開されます。 セキュリティインシデントは、SECURITY.md に則って報告してください。
  2. 行動規範 における通報とモデレーションは継続されます。

12 月で変わること

  1. Electron 28.0.0 は 12 月 5 日にリリースされます。 Electron 28 以降、12 月中に新しい安定版のリリースはありません。
  2. 12 月の最後の 2 週間は、ナイトリーやアルファのリリースはありません。
  3. いくつかの例外を除いて、プルリクエストのレビューやマージはしません。
  4. どのリポジトリでも Issue トラッカーは更新されません。
  5. メンテナからの Discord デバッグのヘルプはありません。
  6. ソーシャルメディアコンテンツの更新はありません。

今後について

今年で 3 年目となる静養期間の実験です。1 か月の休養とその後の通常リリース維持のバランスは、これまで多くの成功を収めてきました。 そのため、これを今後のリリースカレンダーの定期項目とすることにしました。 今後も毎年最後の安定版リリースの際にはお知らせを掲載する予定です。

皆さん、2024 年にまたお会いしましょう!

· 読むのにかかる時間 1 分

Electron 27.0.0 がリリースされました! これには Chromium 118.0.5993.32、V8 11.8、Node.js 18.17.1 へのアップグレードが含まれています。


Electron チームは、Electron 27.0.0 のリリース発表にワクワクしています! npm install electron@latest から npm でインストールするか、リリースウェブサイト からダウンロードできます。 このリリースの詳細は続きをご覧ください。

フィードバックがあれば、TwitterMastodon で共有するか、コミュニティ Discord にご参加ください! バグや機能の要望は Electron の Issue トラッカー で報告できます。

注目すべき変更

累積的変更

破壊的変更

削除: macOS 10.13 / 10.14 のサポート

macOS 10.13 (High Sierra) および macOS 10.14 (Mojave) は Chromium でサポートされなくなりました。

旧バージョンの Electron はこれらのオペレーティングシステムでも引き続き動作しますが、Electron v27.0.0 以降の動作には macOS 10.15 (Catalina) 以降が必要です。

非推奨: ipcRenderer.sendTo()

ipcRenderer.sendTo() API は非推奨となりました。 これは、レンダラー間で MessageChannel を設定するように置き換える必要があります。

IpcRendererEventsenderIdsenderIsMainFrame のプロパティも非推奨になりました。

削除: systemPreferences でのカラースキームイベント

以下の systemPreferences のイベントは削除されました。

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

代わりに nativeTheme の新しいイベントである updated を使用してください。

// 削除されました
systemPreferences.on('inverted-color-scheme-changed', () => {
/* ... */
});
systemPreferences.on('high-contrast-color-scheme-changed', () => {
/* ... */
});

// こちらで置き換えてください
nativeTheme.on('updated', () => {
/* ... */
});

削除: webContents.getPrinters

webContents.getPrinters メソッドは削除されました。 代わりに webContents.getPrintersAsync を使用してください。

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

// 削除されました
console.log(w.webContents.getPrinters());
// こちらで置き換えてください
w.webContents.getPrintersAsync().then((printers) => {
console.log(printers);
});

削除: systemPreferences.{get,set}AppLevelAppearancesystemPreferences.appLevelAppearance

systemPreferences.appLevelAppearance プロパティと同様に、systemPreferences.getAppLevelAppearancesystemPreferences.setAppLevelAppearance メソッドも削除されました。 代わりに nativeTheme モジュールを使用してください。

// 削除されました
systemPreferences.getAppLevelAppearance();
// こちらで置き換えてください
nativeTheme.shouldUseDarkColors;

// 削除されました
systemPreferences.appLevelAppearance;
// こちらで置き換えてください
nativeTheme.shouldUseDarkColors;

// 削除されました
systemPreferences.setAppLevelAppearance('dark');
// こちらで置き換えてください
nativeTheme.themeSource = 'dark';

削除: systemPreferences.getColor での alternate-selected-control-text の値

systemPreferences.getColor での alternate-selected-control-text の値は削除されました。 代わりに selected-content-background を使用してください。

// 削除されました
systemPreferences.getColor('alternate-selected-control-text');
// こちらで置き換えてください
systemPreferences.getColor('selected-content-background');

新機能

  • アプリのアクセシビリティの透明度設定の API を追加 #39631
  • chrome.scripting 拡張機能 API のサポートを追加 #39675
  • WaylandWindowDecorations を既定で有効化 #39644

24.x.y サポートの終了

Electron 24.x.y はプロジェクトの サポートポリシー に則りサポート終了となりました。 開発者とアプリケーションは新しいバージョンの Electron にアップグレードすることを推奨します。

E27 (Oct'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

22.x.y 延長サポートの終了

今年初め、Electron チームは Chrome の Windows 7/8/8.1 のサポート延長に合わせて、Electron 22 のサポート終了予定日を 2023 年 5 月 30 日から 2023 年 10 月 10 日に延長しました (詳細は さらば、Windows 7/8/8.1 をご参照ください)。

Electron 22.x.y はプロジェクトの サポートポリシー とこのサポート延長に則りサポート終了となりました。 これにより、最新の 3 つの安定メジャーバージョンへのサポートに戻り、Windows 7/8/8.1 の公式サポートは終了します。

次回予告

短期的には、Chromium、Node、V8 といった Electron を構成する主要コンポーネントの開発に遅れないでチームが注力し続けるでしょう。

Electron の公開タイムラインはこちら になります。

将来の変更の詳細については、予定されている破壊的変更 のページをご参照ください。

· 読むのにかかる時間 1 分

CVE-2023-4863: WebP のヒープバッファオーバーフロー が公開されたことで、この 1 週間以上は webp を描画するソフトウェアの新規リリースの連続でした。macOS、iOS、Chrome、Firefox、そして多くの Linux ディストリビューションすべてが更新を受け取ったことでしょう。 これは Citizen Lab の調査に伴うもので、「ワシントン DC を拠点とする市民団体」の使用する iPhone が iMessage 内でゼロクリック攻撃を受けたことを発見したものです。

Electron も同日、新バージョンをリリースしました。もしあなたのアプリがユーザー提供のコンテンツを描画する場合、Electron のバージョンを更新すべきです。Electron の v27.0.0-beta.2、v26.2.1、v25.8.1、v24.8.3、v22.3.24 すべてに、webp 画像のレンダリングを行うライブラリ libwebp の修正版を含んでいます。

「画像をレンダリングする」という無邪気な操作が、潜在的に危険な行為であることを私たち全員が再認識した今、私たちはこの機会を利用して、Electron にさらなる大きな攻撃が来た時、付属のプロセスサンドボックスでそれが何であろうとその爆発半径を制限できることを皆さんにお知らせしたいと思います。

サンドボックスは Electron v1 以来ずっと利用可能で、v20 ではデフォルトで有効になっています。しかし、多くのアプリ (特に以前からあるアプリ) はコードのどこかで sandbox: false としていたり、nodeIntegration: true になっていることがあります。これらは明示的に sandbox を設定しない限り、等しくサンドボックスを無効化します。 そのような行いも理解できます。ご寵愛頂いてきた方であれば、おそらく require("child_process")require("fs") を HTML/CSS と同じコードに投げ込んで実行する強力さを味わってきたことでしょう。

どうやって サンドボックスに移行するのかについて話す前に、まずは なぜ 移行したいのかについてご説明します。

サンドボックスは、すべてのレンダラープロセスを硬い檻で囲い、内部で何が起ころうと、コードが制限された環境内で実行されることを保証します。 コンセプトとしては Chromium よりもずっと古く、すべての主要なオペレーティングシステムで一つの機能として提供されています。 Electron と Chromium のサンドボックスは、これらのシステム機能の上に構築されています。 ユーザー生成コンテンツを表示しない場合でも、レンダラーが侵害される可能性を考慮すべきです。サプライチェーン攻撃のような巧妙なシナリオから、ちょっとしたバグのような単純なシナリオまで、レンダラーはあなたが意図しない動作をする可能性があります。

そうなったプロセスは CPU サイクルとメモリを自由に使うことができます。サンドボックスはこういった恐ろしい筋書きをかなり軽減してくれます。 プロセスはディスクに書き込んだり、自分自身のウィンドウを表示したりできません。 例の libwep バグの場合、サンドボックスは攻撃者がマルウェアをインストールしたり実行したりできないようにします。 実際、従業員の iPhone を狙ったオリジナルの Pegasus 攻撃の場合、通常だとサンドボックス化されている iMessage の境界を突破して携帯電話へのアクセスを得るために、サンドボックス化されていない画像処理を特に狙っていました。 この例のような CVE が発表された場合、Electron アプリを安全なバージョンにアップグレードする必要があります。しかし、その間に攻撃者が起こせる被害は劇的に制限されます。

Electron アプリケーションを sandbox: false から sandbox: true に移行するのは大変な作業です。 というのも、Electron セキュリティガイドライン の最初の草稿を私自身が書いたにもかかわらず、私自身のアプリは 1 つも移行できていないからです。 それらは今週末に変更いたしましたので、皆さんも変更してみることをお勧めします。

変更行数に怯える必要はありません。このほとんどは &lt;code&gt;package-lock.json&lt;/code&gt; のものです。

取り組むべきことは 2 つあります。

  1. preload スクリプトや実際の WebContents で Node.js のコードを使用している場合は、Node.js とのやり取りをすべてメインプロセス (言うなればユーティリティプロセス) に移す必要があります。 レンダラーがの強力さを考えると、コードの大部分はリファクタリングの必要がない可能性が高いです。

    プロセス間通信 のドキュメントもご参照ください。 私の場合、多くのコードを移動させて ipcRenderer.invoke()ipcMain.handle() でラップすれば、メインプロセスは簡単ですぐに終わりました。 ここであなたの API 設計にはお気をつけください。もし executeCodeAsRoot(code) のような API を作成したら、サンドボックスはユーザーを守れなくなります。

  2. サンドボックスを有効にすると、プリロードスクリプトの Node.js 統合が無効になるため、require("../my-script") を使用できなくなります。 つまり、プリロードスクリプトは単一のファイルである必要があります。

    この実現には複数の方法があります。Webpack、esbuild、parcel、rollup はすべて、この役割を担います。 私は Electron Forge の優れた Webpack プラグイン を使いました。同じくらい人気のある electron-builder のユーザーの方は、electron-webpack を利用できるでしょう。

これで全てです。Webpack の巨大なパワーを使いこなすために頭を悩ませたことや、他の方法へコードをリファクタリングする機会にしようと決めたことも含めると、全体の処置には 4 日ほどかかりました。

· 読むのにかかる時間 1 分

Electron 26.0.0 がリリースされました! これには Chromium 116.0.5845.62、V8 11.2、Node.js 18.16.1 へのアップグレードが含まれています。 詳しくは以下をご覧ください!


Electron チームは、Electron 26.0.0 のリリース発表にワクワクしています! npm install electron@latest から npm でインストールするか、リリースウェブサイト からダウンロードできます。 このリリースの詳細は続きをご覧ください。

フィードバックがあれば、Twitterで共有するか、コミュニティ Discordに参加してください! バグや機能の要望は Electron の Issue トラッカー で報告できます。

注目すべき変更

累積的変更

破壊的変更

非推奨: webContents.getPrinters

webContents.getPrinters メソッドは非推奨となりました。 代わりに webContents.getPrintersAsync を使用してください。

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

// 非推奨
console.log(w.webContents.getPrinters());
// こちらで置き換えてください
w.webContents.getPrintersAsync().then((printers) => {
console.log(printers);
});

非推奨: systemPreferences.{get,set}AppLevelAppearancesystemPreferences.appLevelAppearance

systemPreferences.appLevelAppearance プロパティと同様に、systemPreferences.getAppLevelAppearancesystemPreferences.setAppLevelAppearance メソッドも非推奨になりました。 代わりに nativeTheme モジュールを使用してください。

// 非推奨
systemPreferences.getAppLevelAppearance();
// こちらで置き換えてください
nativeTheme.shouldUseDarkColors;

// 非推奨
systemPreferences.appLevelAppearance;
// こちらで置き換えてください
nativeTheme.shouldUseDarkColors;

// 非推奨
systemPreferences.setAppLevelAppearance('dark');
// こちらで置き換えてください
nativeTheme.themeSource = 'dark';

非推奨: systemPreferences.getColor での alternate-selected-control-text の値

systemPreferences.getColor での alternate-selected-control-text の値は非推奨になりました。 代わりに selected-content-background を使用してください。

// 非推奨
systemPreferences.getColor('alternate-selected-control-text');
// こちらで置き換えてください
systemPreferences.getColor('selected-content-background');

新機能

  • safeStorage.setUsePlainTextEncryptionsafeStorage.getSelectedStorageBackend の API を追加しました。 #39107
  • safeStorage.setUsePlainTextEncryptionsafeStorage.getSelectedStorageBackend の API を追加しました。 #39155
  • ipcRenderer.sendTo() 経由で送信されたメッセージに senderIsMainFrame を追加しました。 #39206
  • Menu にキーボードで呼び出されたときのフラグを立てるサポートが追加されました。 #38954

23.x.y サポートの終了

Electron 23.x.y はプロジェクトの サポートポリシー に則りサポート終了となりました。 開発者とアプリケーションは新しいバージョンの 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

次回予告

短期的には、Chromium、Node、V8 といった Electron を構成する主要コンポーネントの開発に遅れないでチームが注力し続けるでしょう。

Electron の公開タイムラインはこちら になります。

将来の変更の詳細については、予定されている破壊的変更 のページをご参照ください。