Electron チームは、Electron 6.0.0 のリリース発表にワクワクしています! npm install electron@latest から npm でインストールするか、リリースウェブサイト からダウンロードできます。 このリリースには、アップグレード、修正、新機能が含まれています。 新機能たちと共に何を作るのか、楽しみにしています! このリリースの詳細については下に続きます。是非ご意見をお聞かせください!

新機能​

今日は Electron プロジェクトにとって初めてのことが起こりました。Electron の安定版リリースが、対応する Chrome 安定版リリース と 同日に リリースされたのです! 🎉

Electron の機能の多くは、Chromium、Node.js、V8 といったコアコンポーネントによって提供されています。 Electron では、これらのプロジェクトが最新のものになるように維持し、JavaScript の新機能、パフォーマンスの向上、セキュリティ修正をユーザーに提供しています。 これらの各パッケージについて、Electron 6 ではメジャーバージョンを更新しています。

• Chromium 76.0.3809.88
  • 74 の新機能
  • 75 の新機能
  • 76 の新機能
• Node.js 12.4.0
  • Node 12.4.0 ブログ記事
• V8 7.6.303.22
  • V8 7.6 ブログ記事

このリリースには、Electron の API の改善も含まれます。 リリースノート により詳細なリストがありますが、ここではハイライトを紹介します。

Promise 化​

Electron 6.0 でも 5.0 から始まった近代化 イニシアチブ を継続し、Promise のサポート改善を行っています。

これらの関数は Promise を返すようになりました。従来のコールバックベースの呼び出しもサポートしています。

• contentTracing.getCategories() #16583
• contentTracing.getCategories() #16583
• contentTracing.getTraceBufferUsage() #16600
• contents.executeJavaScript() #17312
• cookies.flushStore() #16464
• cookies.get() #16464
• cookies.remove() #16464
• cookies.set() #16464
• dialog.showCertificateTrustDialog() #17181
• inAppPurchase.getProducts() #17355
• inAppPurchase.purchaseProduct()#17355
• netLog.stopLogging() #16862
• session.clearAuthCache() #17259
• session.clearCache() #17185
• session.clearHostResolverCache() #17229
• session.clearStorageData() #17249
• session.getBlobData() #17303
• session.getCacheSize() #17185
• session.resolveProxy() #17222
• session.setProxy() #17222
• webContents.hasServiceWorker() #16535
• webContents.printToPDF() #16795
• webContents.savePage() #16742
• webFrame.executeJavaScript() #17312
• webFrame.executeJavaScriptInIsolatedWorld() #17312
• webviewTag.executeJavaScript() #17312

これらの関数には、同期と Promise ベースの非同期、2 つの形式があります。

• dialog.showMessageBox()/dialog.showMessageBoxSync() #17298
• dialog.showOpenDialog()/dialog.showOpenDialogSync() #16973
• dialog.showSaveDialog()/dialog.showSaveDialogSync() #17054

これらの関数は Promise を返すようになりました。

• app.dock.show() #16904

Electron Helper (Renderer).app、Electron Helper (GPU).app、Electron Helper (Plugin).app​

Hardened Runtime を有効にするためには、書き込みと実行が可能なメモリや異なるチーム ID で署名されたコードの読み込みなどを制限するために、特別なコード署名権限を Helper に付与する必要がありました。

Chromium の Helper アプリに 3 つの新しい種別を 追加しました。1 つはレンダラー用 (Electron Helper (Renderer).app)、1 つは GPU プロセス用 (Electron Helper (GPU).app)、1 つはプラグイン用 (Electron Helper (Plugin).app) です。

electron-osx-sign で Electron アプリのコード署名を行っている方は、ビルドロジックを変更しなくても構いません。 カスタムスクリプトでアプリをコード署名する場合は、3 つの新しい Helper アプリケーションを正しくコード署名しているかどうか確認する必要があります。

これらの新しいヘルパーと共にアプリケーションを正しくパッケージするには、 electron-packager@14.0.4 以上を使用する必要があります。 electron-builder を使用している方は、この Issue を確認して、これらの新しいヘルパーのサポート状況を確認してください。

破壊的変更​

• これは、レンダラープロセスにロードされるネイティブ Node モジュールは N-API か コンテキス対応 であるという将来の要件に対応する作業の、下地づくりとして始めています。 この変更を行う理由は、パフォーマンス高速化、セキュリティ強化、保守作業を軽減するためです。 提案された時系列を含む詳細は、この Issue を読んでください。 この変更は Electron v11 で完了する予定です。

• net.IncomingMessage ヘッダは、Node.js の動作、特に set-cookie の値や重複するヘッダの処理方法が厳密に一致するように 少し変更 されました。 #17517.

• shell.showItemInFolder() は void を返す非同期呼び出しになりました。 #17121

• アプリで app.getPath('log') を使用する前に、新しい関数 app.setAppLogPath() を呼び出して明示的にログパスを設定しなければならないようになりました。 #17841

3.x.y サポートの終了​

サポートポリシー に基づき、3.x.y は役目を終えました。 開発者とアプリケーションは新しいバージョンの Electron にアップグレードすることを推奨します。

App のフィードバックプログラム​

テストには引き続き アプリフィードバックプログラム を使用します。 このプログラムに参加するプロジェクトは、そのアプリで Electron ベータ版をテストします。見返りとして、発見した新しいバグは安定版リリースのために優先します。 参加や詳細については、当プログラムに関するブログ記事を確認してください。

次回予告​

短期的には、Chromium、Node、V8 といった Electron を構成する主要コンポーネントの開発に遅れないでチームが注力し続けるでしょう。 リリース日について約束しないように注意していますが、予定では約四半期ごとに新しいメジャーバージョンの Electron を、各コンポーネントの新しいバージョンに対してリリースします。 仮 7.0.0 スケジュール では、Electron 7 開発ライフサイクルの主要な日付を示してあります。 また、Electron のバージョン管理の詳細については バージョン管理のドキュメントを参照 してください。

今後のバージョンの Electron で予定されている破壊的変更の詳細は、予定されている破壊的変更のドキュメントを参照してください。

🎉 Electron は 12 週ごとに新しいメジャー安定バージョンをリリースします! 🎉

⚡️ なんて速さだ! でもなんで?​

簡単に言えば、Chromium は更新を止めないので Electron も遅くなりません。

Chromium は、一貫した 6 週間の スケジュール でリリースされます。 Electron で Chromium の最新バージョンを提供するには、そのスケジュールを追う必要があります。 Chromium のリリースサイクルに関する詳細は こちら を参照してください。

🚀 なんで 12 週ごとに?​

6 週ごとに、新しい機能、バグ修正/セキュリティ修正、V8 の改善が施された新しい Chromium リリースが出ます。 Electron ユーザーはこの変更を明確に待ち望んでおり、他の Chromium 安定リリースごとに安定リリース日を合わせていました。 最初に、Electron v6.0.0 には M76 が含まれます。これは、Chromium M76 と同じリリース日である 2019 年 7 月 30 日 で安定版リリースを予定しています。

🚧 私と自作 Electron アプリはどうなりますか?​

新しい Chromium と V8 の機能と修正プログラムに以前よりも早くアクセスできるようになります。 重要なのは、これら新しい変更がいつ いつ 行われるかもわかるため、以前よりも良質な情報で計画できるということです。

Electron チームは、新しい順に 3 つのメジャーバージョンを 継続サポート します。 例えば、v6.0.0 が 2019 年 7 月 30 日に安定版になった 場合、v6.x、v5.x、v4.x はサポートします。v3.x はサポート終了になります。

💬 App のフィードバックプログラム​

アプリフィードバックプログラム に参加して、ベータリリースと安定化のテストに役立ててください。 このプログラムに参加するプロジェクトは、そのアプリで Electron ベータ版をテストします。見返りとして、発見した新しいバグは安定版リリースのために優先します。

📝 Electronリリースの略歴​

v3.0.0 より前の安定版リリースに関する決定は、スケジュールに従っていませんでした。 v3.0.0 と v4.0.0 において、プロジェクトに内部スケジュールを追加しました。 今年の初めに Electron v5.0.0 の安定版リリース日を初めて公開することにしました。 安定版リリース日の発表は全体として好意的に受け止められており、今後のリリースでも継続リリースできることを楽しみにしています。

これらのアップグレード関連の作業を効率化するために、 ガバナンス システム内に アップグレード と リリース の作業グループが作成されました。 これらにより、作業をより優先順位付けて委任できます。これは後のリリースごとに効果が出てくるでしょう。

Chromium のケイデンスと比較すると、我々の新たなケイデンスは以下のように位置します。

📨 ご質問は、info@electronjs.org までメールでお問い合わせください。

Electron チームは、Electron 5.0.0 のリリース発表にワクワクしています! npm を使って npm install electron@latest でインストールするか、リリースページ から tarball をダウンロードできます。 このリリースには、アップグレード、修正、新機能が含まれています。 新機能たちと共に何を作るのか、楽しみにしています! このリリースの詳細については下に続きます。是非ご意見をお聞かせください!

何が新しくなったの?​

Electron の機能の多くは、Chromium、Node.js、V8 といったコアコンポーネントによって提供されています。 Electron では、これらのプロジェクトが最新のものになるように維持し、JavaScript の新機能、パフォーマンスの向上、セキュリティ修正をユーザーに提供しています。 これらの各パッケージについて、Electron 5 ではメジャーバージョンを更新しています。

• Chromium 73.0.3683.119
  • 70 の新機能
  • 71 の新機能
  • 72 の新機能
  • 73 の新機能
• Node.js 12.0.0
  • Node 12 ブログ記事
• V8 7.3.492.27.
  • 新しい JS の機能

Electron 5 には、Electron 固有の API の改善も含まれます。 主な変更点の概要は以下の通りです。変更点の全リストは Electron v5.0.0 リリースノート を参照してください。

Promise 化​

Electron 5 でも Promise 化イニシアチブ の取り組みを継続しており、Electron のコールバックベース API を Promise を使用したものへと変換しています。 これらの API が Electron 5 で変換されています。

• app.getFileIcon
• contentTracing.getCategories
• contentTracing.startRecording
• contentTracing.stopRecording
• debugger.sendCommand
• Cookie API
• shell.openExternal
• webContents.loadFile
• webContents.loadURL
• webContents.zoomLevel
• webContents.zoomFactor
• win.capturePage

macOS 向けシステムカラーアクセス​

macOS システムカラーにアクセスするために、これらの関数が systemPreferences に変更または追加されました。

• systemPreferences.getAccentColor
• systemPreferences.getColor
• systemPreferences.getSystemColor

プロセスメモリ情報​

現在のプロセスに関するメモリ使用量の統計情報を取得する関数 process.getProcessMemoryInfo が追加されました。

remote API の更なるフィルタリング​

remote API のセキュリティを向上させるため、remote.getBuiltin、remote.getCurrentWindow、remote.getCurrentWebContents、<webview>.getWebContents を フィルタリング できる、新しい remote のイベントが追加されました。

BrowserWindow で複数の BrowserView​

BrowserWindow が一つの BrowserWindow 内で複数の BrowserViewを管理できるようになりました。

破壊的変更​

パッケージしたアプリのデフォルト​

パッケージしたアプリは、デフォルトのアプリと同じように動作するようになりました。デフォルトのアプリケーションメニューがそのアプリになければ作成され、アプリが window-all-closed イベントを処理しなければ、そのイベントは自動的に処理されます。

混合サンドボックス​

混合サンドボックスモードはデフォルトで有効になりました。 これまでは混合サンドボックスモードも有効になっている場合にのみサンドボックス化されていました。これで、sandbox: true で起動したレンダラーが実際にサンドボックス化されるようになりました。

セキュリティの改善​

セキュリティ向上のため、nodeIntegration と webviewTag の省略値が false になりました。

スペルチェッカーが非同期に​

SpellCheck API が変更され、非同期の実行結果 を提供するようになりました。

非推奨​

以下の API は Electron 5.0.0 で新たに非推奨となり、6.0.0 で削除される予定のものです。

arm と arm64 向けの mksnapshot バイナリ​

arm と arm64 向けの mksnapshot のネイティブバイナリは非推奨となり、6.0.0 で削除されます。 arm と arm64 向けの snapshots は x64 バイナリで作成できます。

WebContents での ServiceWorker API​

WebContents 上での ServiceWorker API は後に削除するために非推奨となります。

• webContents.hasServiceWorker
• webContents.unregisterServiceWorker

サンドボックス化 WebContents での自動モジュール​

セキュリティ向上のため、以下のモジュールの require を介した直接使用は非推奨になります。代わりにサンドボックス化された WebContents 内で remote.require を使用してください。

• electron.screen
• child_process
• fs
• os
• パス

webFrame Isolated World APIs​

webFrame.setIsolatedWorldContentSecurityPolicy、 webFrame.setIsolatedWorldHumanReadableName、webFrame.setIsolatedWorldSecurityOrigin は webFrame.setIsolatedWorldInfo と入れ替わりで非推奨になりました。

混合サンドボックス​

enableMixedSandbox と --enable-mixed-sandbox コマンドラインスイッチは互換性のためにまだ残りますが、非推奨となり効果も無くなります。

2.0.x サポートの終了​

サポートするバージョンのポリシー に基づき、2.0.x は役目を終えました。

App のフィードバックプログラム​

テストには引き続き アプリフィードバックプログラム を使用します。 このプログラムに参加するプロジェクトは、そのアプリで Electron ベータ版をテストします。見返りとして、発見した新しいバグは安定版リリースのために優先します。 参加や詳細については、当プログラムに関するブログ記事を確認してください。

次回予告​

短期的には、Chromium、Node、V8 といった Electron を構成する主要コンポーネントの開発に遅れないでチームが注力し続けるでしょう。 リリース日について約束しないように注意していますが、予定では約四半期ごとに新しいメジャーバージョンの Electron を、各コンポーネントの新しいバージョンに対してリリースします。 仮 6.0.0 スケジュール では、Electron 6 開発ライフサイクルの主要な日付を示してあります。 また、Electron のバージョン管理の詳細については バージョン管理のドキュメントを参照 してください。

今後のバージョンの Electron で予定されている破壊的変更の詳細は、予定されている破壊的変更のドキュメントを参照してください。

C++ や Objective-C で記述された Electron の機能は、どのように JavaScript となってエンドユーザーが利用できるのでしょうか。

背景​

Electron は、開発者の参入障壁を取り下げることを主目的とした JavaScript プラットフォームで、プラットフォーム固有の実装を気にせずに堅牢なデスクトップアプリを構築できます。 ただし、Electron 自身の中核には、特定システムの言語で記述するようなプラットフォーム固有の機能も必要です。

実際には Electron がネイティブコードを扱うので、単一の JavaScript API に集中できます。

一体、どのように動作しているのでしょうか。 C++ や Objective-C で記述された Electron の機能は、どのように JavaScript となってエンドユーザーが利用できるのでしょうか。

この道筋を追いかけるために、app モジュール から始めましょう。

lib/ ディレクトリ内の app.ts ファイルを開くと、その上部に以下のようなコードの行があります。

const binding = process.electronBinding('app');

この行は、開発者が使用している C++/Objective-C モジュールを JavaScript にバインドする Electron の仕組みをまさに表しています。 この関数は ElectronBindings クラスの、ヘッダーと 実装ファイル によって作成されます。

process.electronBinding​

これらのファイルは Node.js の process.binding のように動作する process.electronBinding 関数を追加します。 process.binding は Node.js の require() メソッドよりローレベルの実装です。ただし、他の JS で書かれたコードではなくネイティブコードを require することができます。 このカスタム process.electronBinding 関数は Electron からネイティブコードをロードする機能を与えます。

トップレベルの JavaScript モジュール (app など) がこのネイティブコードを require する場合、そのネイティブコードの状態はどのように決定および設定されるのでしょうか。 そのメソッドはどこまで JavaScript に公開されるのでしょうか。 プロパティではどうなのでしょうか。

native_mate​

現時点では、この疑問には native_mate が答えてくれます。これは、C++ と JavaScript の間で型をマーシャリングしやすくする Chromium の gin ライブラリ のフォークです。

native_mate/native_mate の中には、object_template_builder のヘッダーと実装ファイルがあります。 これにより、JavaScript 開発者が望むように適合する形式のネイティブコードでモジュールを形成します。

mate::ObjectTemplateBuilder​

すべての Electron モジュールを object として見ると、object_template_builder で構築する理由がわかりやすくなります。 このクラスは、C++ で記述された Google によるオープンソースで高性能の JavaScript および WebAssembly エンジン、V8 が公開するクラスの上に構築されます。 V8 は JavaScript (ECMAScript) の仕様を実装しているため、ネイティブ機能の実装を JavaScript の実装に直接関連付けることができます。 たとえば、v8::ObjectTemplate は専用のコンストラクタ関数とプロトタイプなしで JavaScript オブジェクトを提供します。 Object[.prototype] を使用するため、JavaScript での Object.create() と等価です。

この動作確認は、アプリモジュールの実装ファイル atom_api_app.cc を参照してください。 下部には以下のようなものがあります。

mate::ObjectTemplateBuilder(isolate, prototype->PrototypeTemplate())
    .SetMethod("getGPUInfo", &App::GetGPUInfo)

上記の行では、.SetMethod が mate::ObjectTemplateBuilder で呼び出されます。 .SetMethod を ObjectTemplateBuilder クラスの任意のインスタンスで呼び出し、以下の構文で JavaScript の Object プロトタイプ にメソッドを設定できます。

.SetMethod("method_name", &function_to_bind)

これは以下の JavaScript と等価です。

function App{}
App.prototype.getGPUInfo = function () {
  // ここに実装
}

このクラスには以下のようなモジュールにプロパティをセットする関数も含まれます。

.SetProperty("property_name", &getter_function_to_bind)

または

.SetProperty("property_name", &getter_function_to_bind, &setter_function_to_bind)

これらは、以下のような Object.defineProperty による JavaScript 実装になります。

function App {}
Object.defineProperty(App.prototype, 'myProperty', {
  get() {
    return _myProperty
  }
})

aND

function App {}
Object.defineProperty(App.prototype, 'myProperty', {
  get() {
    return _myProperty
  }
  set(newPropertyValue) {
    _myProperty = newPropertyValue
  }
})

これによって開発者が予期するようなプロトタイプとプロパティで形成された JavaScript オブジェクトを作成することができ、よりローレベルのシステムで実装された関数とプロパティでもよりはっきりと推論します!

特定のモジュールメソッドの実装場所に関する決定は、それ自体が複雑かつ多くの場合に置いて非決定的です。これについては今後の記事で補います。

Electron がデスクトップアプリケーションで人気を博すにつれて、取り組むチームも成長しました。さまざまな企業で働き、タイムゾーンに住み、関心を持つ専任メンテナーが増えています。 よりスムーズに成長し続けることができるように、我々にガバナンス機構を導入します。

なぜ変革するのですか?​

Electron プロジェクトの人々は、世界中のタイムゾーンに居るボランティア、専任メンテナー、Electron に依存しているいくつかの企業と調整しています。 これまで、形式的でない調整で上手くいっていました。しかし、チームが成長するにつれてこのやり方がスケールしないことがわかりました。 また、新規のコントリビューターをプロジェクト内に呼び戻しやすくしたいのです。

ワーキンググループ​

Electron ガバナンスは、プロジェクトのさまざまな部分を担当するワーキンググループを含みます。 我々は以下の 7 つのグループから始めることにします。

• コミュニティ & 安全性: 行動規範 の問題を執る。
• ドキュメント & ツール: 外部向けツール (Fiddle、Forge など) の監督と Electron の ドキュメント化 を行う。
• 支援: Electron コミュニティの成長を支援する。
• リリース: リリースが安定かつ予定通りであることを確認する。
• セキュリティ: セキュリティテストを行い、セキュリティの問題に対応する。
• アップグレード: 新しいバージョンの V8、Chromium、Node などの、上流のアップグレードを統合する。
• ウェブサイト: Electron のウェブサイト を維持し改善する。

これらのグループは相互に調整し合いますが、グループは各々のの会議スケジュールと議題を保持し、生産的に活動してください。 これらのグループの詳細は ガバナンスリポジトリ で見ることができます。

Electron プロジェクトの方向性は変わりますか?​

これは Electron の方向性に直接影響しません。 私たちの戦略が成功した場合、ワーキンググループは、新しいコントリビューターが関心のあるトピックを見つけやすくし、それぞれの日常業務と無関係の議論を他グループに移行することで、メンテナーの活動が楽になります。 こうなると、制限されない人々の間接的な働きかけがより影響するでしょう。

詳細はどこですか?​

• ガバナンス レポジトリ と チャーター に、新しいガバナンス構造に関する情報があります。
• 各ワーキンググループはそれぞれのページを保有しています。コミュニティ、ドキュメント & ツール、支援、リリース、セキュリティ、アップグレード、ウェブサイト があります。
• メンテナと連絡するには、Issue を開く か、info@electronjs.org までメールでお問い合わせください。

Chrome に高レベルの重大な脆弱性が発見されました。Electron を含む Chromium ベースのすべてのソフトウェアに影響します。

この脆弱性は CVE-2019-5786 と命名されています。 詳細は Chrome ブログ記事 を参照してください。

Chrome でこの脆弱性が悪用されているという報告があります。なるべく早く Electron を更新することを強く推奨します。

影響範囲​

これはサードパーティや信頼できない JavaScript を実行する恐れのある Electron アプリケーションに影響します。

緩和策​

影響を受けるアプリは、パッチを当てたバージョンの Electron にアップグレードする必要があります。

以下の通り、この脆弱性に対する修正を含む新しいバージョンの Electron を公開しました。

• 4.0.8
• 3.1.6
• 3.0.16
• 2.0.18

Electron 5 の最新ベータ版は Chromium 73 を追っていたので、パッチは適用済みです。

• 5.0.0-beta.5

詳細情報​

この脆弱性は Google の Threat Analysis Group の Clement Lecigne によって発見され、Chrome チームに報告されました。 その Chrome ブログ記事は こちら です。

Electron アプリを堅牢に保つベストプラクティスの詳細は、セキュリティチュートリアル を参照してください。

Electron の脆弱性を報告したい方は、GitHub セキュリティアドバイザリ をご提出ください。

Electron チームは 32 ビット Linux (ia32 / i386) に対するサポートを Electron v4.0 から中止します。 32 ビットを元にした Linux 環境をサポートする最後のバージョンは Electron v3.1 です。 このバージョンでは、 Electron v6 がリリースされるまでサポートリリースを受けられます。 64 ビット Linux 及び armv7l のサポートは変わらず続行されます。

Electron は何のサポートをやめるのですか?​

コンピュータに貼られたシールや、ソフトウェアをダウンロードするときの選択肢として "64 ビット" 及び "32 ビット" の説明を見たことがあるかもしれません。 この語は、特定のコンピュータアーキテクチャを表します。 1990 年代と 2000 年代初期に作成されたほとんどのコンピュータは、 32 ビットアーキテクチャに基づいた CPU を使用していましたが、後に作られたものは、より新しく強力な 64 ビットアーキテクチャに基づくようになりました。 Nintendo 64 (分かりますか?) と PlayStation 2 は新しいアーキテクチャを持つデバイスで最初に広く利用されたものでした。 2010 年以降に販売されたコンピュータのほとんどには、 64 ビットプロセッサが使われていました。 Google は 32 ビット向けの Chrome リリースを 2016 年 3 月にやめたほか、 Canonical は 32 ビットデスクトップ向けイメージの配布を 2017 年にやめた後、 Ubuntu 18.10 で 32 ビットのサポートを終了しました。このように、 32 ビットアーキテクチャのサポートは縮小しています。 Arch Linux、Elementary OS や他の著名な Linux ディストリビューションでは、既に古いプロセッサアーキテクチャのサポートを終了しています。

これまで、 Electron は 32 ビットアーキテクチャ向けのビルドを配布し、サポートしてきました。 リリース v4.0 から、 Electron チームは 32 ビット Linux のバイナリ配布やサポートをできなくなります。

Electron は常に活発的なオープンソースプロジェクトであり、新しいアーキテクチャ向けに Electron をビルドしようとする開発者を奨励したり、助けたりしていきます。

開発者にとっては何を意味しますか?​

32 ビット Linux 用にアプリを配布していない場合、何もする必要はありません。

32 ビット Linux 向け Electron アプリを配布しているプロジェクトでは、どのように進めるかを決める必要があるでしょう。 決定や計画を行うために、Electron 6 がリリースされる まで は Electron 3 で 32 ビット Linux がサポートされます。

ユーザにとっては何を意味しますか?​

あなたが Linux ユーザで、 64 ビットに基づいたシステムで実行しているかどうかが分からない場合、おそらく 64 ビットに基づいたアーキテクチャで実行しているでしょう。 確認するには、 lscpu または uname -m コマンドを端末で実行してください。 どちらかが現在のアーキテクチャを表示するでしょう。

Linux を 32 ビットプロセッサで実行している場合、最近リリースされたソフトウェアでその OS 用のものを見つけるのは困難になってきているはずです。 Electron チームは、 Linux コミュニティの他の著名なメンバーと同じく、 64 ビットに基づいたアーキテクチャへアップグレードすることを推奨します。

Node を子ウィンドウで再度有効にできるというコードの脆弱性が発見されました。

sandbox: true または nativeWindowOpen: true と nodeIntegration: false で BrowserView を開くと、そこから window.open を呼び出すことができます。そうして新しく開いた子ウィンドウでは nodeIntegration が有効な webContents が生成されます。 この脆弱性は、すべてのサポートされているバージョンの Electron に影響します。

緩和策​

この脆弱性に対する修正を含む新しいバージョンの Electron を公開しました。2.0.17、 3.0.15、 3.1.3、 4.0.4、 5.0.0-beta.2 です。 すべての Electron 開発者は、アプリをすぐに最新の安定バージョンに更新することを推奨します。

何らかの理由で Electron バージョンをアップグレードできない場合は、すべての子ウェブコンテンツを無効にすることでこの問題を緩和できます。

view.webContents.on('-add-new-contents', (e) => e.preventDefault());

詳細情報​

この脆弱性は PalmerAL によって発見され、Electron プロジェクトに責任ある形で報告されました。

Electron アプリを堅牢に保つベストプラクティスの詳細は、セキュリティチュートリアル を参照してください。

Electron の脆弱性を報告したい方は、GitHub セキュリティアドバイザリ をご提出ください。

Electron 5.0 でネイティブな Node.js アドオンを使用しようとして問題が発生している場合、 V8 の最新バージョンで動作するように更新する必要があるかもしれません。

さようなら v8::Handle 、こんにちは v8::Local​

2014 年、 V8 チームはローカルハンドルを v8::Local に置き換え、 v8::Handle を非推奨にしました。 Electron 5.0 は v8::Handle が削除されたバージョンの V8 を含んでいるため、それを使用しているネイティブ Node.js アドオンは Electron 5.0 で使用される前に更新する必要があります。

必要なコード変更は最小限ですが、未だ v8::Handle を使用している すべての ネイティブ Node モジュールは Electron 5.0 でのビルドに失敗するため、変更されなければなりません。 Node.js v12 はこの V8 の変更を含んでいるため、 v8::Handle を使用しているモジュールは次のバージョンの Node で動作するために どのみち 更新される必要があるでしょう。

私はネイティブアドオンをメンテナンスしていますが、どうすればいいですか？​

あなたが Node.js 用のネイティブアドオンをメンテナンスしている場合、 v8::Handle が使われている場所がすべて v8::Local に置き換わっていることを確認してください。 前者は後者の別名に過ぎなかったので、この問題に対処するために他の変更を加える必要はありません。

また、 N-API は、Node.js の一部として V8 とは別に管理され、基になる JavaScript エンジンの変更からネイティブアドオンを分離することを目的としています。 詳細については Node.js ウェブサイト内の N-API ドキュメント を参照してください。

ヘルプ! ネイティブアドオンを使用している私のアプリが動作しません!​

アプリで Node.js 用のネイティブアドオンを使用していて、この問題のためにネイティブアドオンがビルドされない場合は、アドオンの作成者に問い合わせて、問題を解決する新しいバージョンがリリースされているかどうかを確認してください。 もしそうでなければ、著者に連絡を取る (または プルリクエストを開く! ) とよいでしょう。

v5.0.0 以降の Electron のリリーススケジュールを初めて公開することにドキドキしています。 これは公開される長期のスケジュールを設定する第一歩です。

v4.0.0 安定版リリースの ブログ記事 で述べたように、およそ四半期ごとにリリース予定です。Chromium のリリースと密接なケイデンスを維持します。 Chromium は、6 週間という非常に速い周期で新バージョンをリリースします。

Electron と Chromium の変遷を並べて見てみましょう。

2018 年の後半、私たちの最優先事項は、より早くリリースして Chromium に追いつくことでした。 これは事前に決めたタイムラインを遵守することで成功しました。 Electron 3.0.0 と 4.0.0 は、各リリース 2 ~ 3 か月のタイムラインでリリースされました。 5.0.0 以降のリリースでもそのペースを続けるつもりです。 ほぼ四半期ごとに Electron のメジャーリリースが行われ、Chromium のリリースペースに追いつきます。 Chromium の安定版リリースに先んじることは常に私たちの目標であり、私たちはそれを着実に進めています。

Node.js や Chromium のように将来の日付を約束したいのですが、まだ その段階ではありません。 将来的には長期的なスケジュールに変化するだろうと楽観視しています。

それを念頭に置いて、v5.0.0 のリリーススケジュールを公開することで第一段階を進めています。 スケジュールは こちら にあります。

ベータ版リリースと安定化のテストに役立てるため、アプリフィードバックプログラム への参加をご検討ください。