メインコンテンツへ飛ぶ

electron/rfcs の紹介

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

Electron の API ワーキング グループ は、Electron のコアへのより大きな変更を支援するために、オープンな Requests for Comments (RFC) プロセスを採用しようとしています。

なぜ RFC なのでしょうか?

要するに、Electron のコアへの重要な変更を実装するプロセスをスムーズにしたいのです。

現在、新しいコードの変更は主に GitHub の Issue とプルリクエストを通じて議論されています。 Electron のほとんどの変更においては、これは良いシステムです。 多くのバグ修正、ドキュメントの変更、さらには新機能も、標準の GitHub フローを介せば非同期的にレビューおよびマージできるほど簡単です。

より重大な変更—たとえば大規模な API サーフェスや、Electron アプリの大部分に影響する重大な変更などの場合、コードの大部分が記述される前のアイデア段階でレビューを行うほうが合理的です。

このプロセスは一般公開されるように設計すべきです。そうすることで、Electron に導入される前に、オープンソースコミュニティ全体が潜在的な変更についてフィードバックを提供しやすくなります。

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

RFC 全体のプロセスは、GitHub 上の electron/rfcs リポジトリに保管されます。 プロセスの手順は、リポジトリの README で詳しく説明しています。

簡単に言うと、electron/rfcs リポジトリに PR が作成されると、RFC は 提唱 になります。 提唱の RFC は次のように遷移します。

  • アクティブ は、PR がリポジトリの main ブランチにマージされた場合になります。つまり、Electron のメンテナが electron/electron での実装に同意できることを意味します。
  • 拒絶 は PR が最終的に拒否された場合になります。
info

RFC が アクティブ になるには、PR が少なくとも 2 人の API ワーキンググループのメンバーによって承認されなければなりません。 マージ前に、RFC は WG メンバーの 3 分の 2 以上の定足数によって開かれた会議で同期的に提示され、全会一致で承認される必要があります。 合意に達した場合、1 か月の最終コメント期間が開始され、その後 PR がマージされます。

実装が electron/electron にマージされたとき、アクティブな RFC は 完了 になります。

誰が参加できますか?

Electron コミュニティの誰もが、RFC を提出したり、electron/rfcs リポジトリにフィードバックを残したりできます!

私たちは、このプロセスを双方向の対話にして、コミュニティの参加を奨励し、将来これらの API を使用する可能性のある Electron アプリからの多様な意見を得たいと考えていました。 現在提唱状態の RFC にフィードバックを残したい方向けに、Electron のメンテナが既に作成したいくつかの RFC を下記します。

クレジット

Electron の RFC プロセスは、多くの確立されたオープンソースの RFC プロセスに基づいてモデル化されました。 多くのアイデアやコピーライティングの主要部分のインスピレーションは、以下から得ました。

"runAsNode" の CVE に関する声明

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

今日このごろ、いくつかの有名な Electron アプリに対して最近提出された公開 CVE について Electron チームが警告を受けました。 CVE は、Electron の 2 つの fuse - runAsNodeenableNodeCliInspectArguments - に関連しており、これらのコンポーネントを積極的に無効化しない場合、遠隔攻撃者がこれらのコンポーネントを介して任意のコードを実行できると誤って主張しています。

これらの CVE が誠意を持って提出されたとは考えていません。 まず、この記述は誤りです - この構成では遠隔コード実行は 不可能です。 第二に、これらの CVE で指摘されている企業は、バグ報奨金プログラムを実施しているにもかかわらず、そのバグを通知されていません。 最後に、問題のコンポーネントを無効にするとアプリのセキュリティが強化されることは信じられますが、その CVE が適切な重大度で登録されているとは考えられません。 「Critical」は最も危険な問題に対して予約されたものですが、今回の場合は明らかに当てはまりません。

CVE は誰でも発行できます。 これはソフトウェア業界全体の健全性にとっては良いことですが、一人のセキュリティ研究者が評判を高めるために「CVE を稼ぐ」ことは役立ちません。

とはいえ、恐ろしい「重大」な深刻度を持つ CVE が存在するだけでエンドユーザーの混乱を招く可能性があることは理解しています。そのためプロジェクトとして、問題に対処するためのガイダンスと支援を提供したいと考えています。

どのような影響がありますか?

CVE をレビューしたところ、Electron チームはこれらの CVE は重大でないと判断しました。

この攻撃者は、ハードウェアに物理的にアクセスするか、完全な遠隔コード実行を実現することによって、マシン上で任意のコマンドを実行できる必要があります。 これは繰り返しとなっています。ここで説明されている脆弱性を利用するには、攻撃者が対象のシステムに既にアクセスできていなければなりません

例えば、Chrome は 脅威モデルで物理的にローカルな攻撃を考慮していません

これらの攻撃は Chrome の脅威モデルの範囲外であると考えています。これは、ユーザとしてデバイスにログインした悪意のあるユーザーや、オペレーティングシステムのユーザアカウントの権限でソフトウェアを実行できる悪意のあるユーザーから Chrome (または任意のアプリケーション) を保護する方法がないためです。 このような攻撃者は、実行可能ファイルや DLL を変更したり、PATH などの環境変数を変更したり、構成ファイルを変更したり、ユーザアカウントが所有するデータを読み取ったり、それを攻撃者自身に電子メールで送信したりできます。 このような攻撃者はデバイスを完全に制御できるため、Chrome が施せる対策では防御を完全に保証できません。 この問題は Chrome に特有のものではありません — すべてのアプリケーションは物理的にローカルなユーザを信頼せざるをえません。

CVE に記載されているエクスプロイトにより攻撃者は、影響を受けるようなアプリを、継承された TCC (透明性、同意、制御) の権限を持つ汎用 Node.js プロセスとして使用できるようになります。 したがって、たとえばアプリにアドレス帳へのアクセスが許可されている場合、攻撃者はそのアドレス帳へのアクセスを継承するアプリを Node.js として実行し、任意のコードを実行できます。 これは一般に「Living Off The Land」攻撃として知られています。 攻撃者は通常、PowerShell や Bash などのツールを用いて任意コード実行をします。

影響はありますか?

デフォルトでは、リリースされている全バージョンの Electron は runAsNodeenableNodeCliInspectArguments の機能が有効です。 Electron Fuses のドキュメント で説明されているように、これらをオフにしていない場合、アプリが「Living Off the Land」攻撃に利用される危険性は同様に高くなります。 繰り返し強調しますが、攻撃者は 既に 被害者のマシン上でコードとプログラムを実行できている必要があります。

緩和策

この問題を軽減する最も簡単な方法は、あなたの Electron アプリの runAsNode の Fuse を無効化することです。 runAsNode ヒューズは、ELECTRON_RUN_AS_NODE 環境変数が尊重されるかどうかを切り替えます。 これらのヒューズを切り替える方法については、Electron Fuses のドキュメント をご参照ください。

注意としてこの Fuse が無効になっている場合、メインプロセスの process.fork はこの環境変数に依存して動作するため、期待通りに動作しなくなることがあります。 代わりに、ユーティリティプロセス を使用することを推奨します。これは、スタンドアロンの Node.js プロセス (SQLite サーバーのプロセスや同様の場合) が必要な多くのユースケースで機能します。

Electron アプリで推奨されるセキュリティのベストプラクティスの詳細については、セキュリティチェックリスト をご覧ください。

Electron 28.0.0

· 読むのにかかる時間 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 の公開タイムラインはこちらで ご覧いただけます。

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

エコシステム 2023 総括

· 読むのにかかる時間 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 の開発体験をさらに向上させる方法について考えていることでしょう。

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

12 月の安息月 (Dec'23)

· 読むのにかかる時間 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 年にまたお会いしましょう!

Electron 27.0.0

· 読むのにかかる時間 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 トラッカー で報告できます。

侵入を防ごう: サンドボックスでアプリを強化

· 読むのにかかる時間 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 つも移行できていないからです。 それらは今週末に変更いたしましたので、皆さんも変更してみることをお勧めします。

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

取り組むべきことは 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 日ほどかかりました。

Electron 26.0.0

· 読むのにかかる時間 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 トラッカー で報告できます。

Electron 25.0.0

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

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


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

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

22.x.y 継続サポート

さらば、Windows 7/8/8.1 で述べた通り、Electron 22 (Chromium 108) の EOL 予定日は 2023 年 5 月 30 日から 2023 年 10 月 10 日へと延長されました。 Electron チームは、2023 年 10 月 10 日までこのプログラムの一部であるセキュリティ修正の Electron 22 へのバックポートを継続する予定です。 10 月のサポート日は Chromium と Microsoft 両方の延長サポート日に従っています。 10 月 11 日時点で、Electron チームは最新から 3 つの安定版メジャーバージョンが Windows 7/8/8.1 サポートすることを終了します。

E25 (May'23)E26 (Aug'23)E27 (Oct'23)
25.x.y26.x.y27.x.y
24.x.y25.x.y26.x.y
23.x.y24.x.y25.x.y
22.x.y22.x.y--

注目すべき変更

  • Chromiumのネットワークスタックを使用して、Electron のネットモジュール内に net.fetch を実装しました。 これは、Node.js の HTTP スタックを使用する Node の fetch()とは異なります。 #36733#36606を参照してください。
  • protocol.handleを追加しました。これは非推奨になった protocol.{register,intercept}{String,Buffer,Stream,Http,File}Protocol を置き換えます。 #36674
  • ChromiumとMicrosoftのWindows 7/8/8.1の非推奨プランと一致するように、Electron 22の拡張サポート。 詳細はこのブログ投稿の最後をご覧ください。

Electron 24.0.0

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

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


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

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