メインコンテンツへ飛ぶ

BrowserView window.open() の脆弱性の修正

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

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


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

緩和策

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

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

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

詳細情報

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

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

Electron の脆弱性を報告する場合は、security@electronjs.org にメールでご連絡お願いします。

Node.js ネイティブアドオンと Electron 5.0

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

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

Electron v5.0.0 タイムライン

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

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


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

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

Electron と Chromium のバージョンを比較する折れ線グラフ

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

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

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

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

Electron 4.0.0

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

Electron チームは、Electron 4 安定版が利用可能になった発表でワクワクしています! electronjs.org からか、npm で npm install electron@latest からインストールできます。 このリリースにはアップグレード、修正、新機能が詰め込んであります。皆さんが何を作るのか待ち遠しいです。 以下にこのリリースの詳細が続きます。是非使用したご意見を共有してください!


何が新しくなったの?

Electron の機能の大部分は、Electron を構成するコアコンポーネントの Chromium、Node.js、V8 によって提供されています。 そのため Electron チームの主な目標は、これらのプロジェクトの変更に可能な限り対応し、Electron アプリを開発する開発者に新しいウェブや JavaScript の機能へのアクセスを提供することです。 このため Electron 4 ではこれらの各コンポーネントのバージョンが大きく変更されています。Electron v4.0.0 には Chromium 69.0.3497.106、Node 10.11.0、V8 6.9.427.24 が入っています。

さらに、Electron 4 には Electron 固有の API への変更が含まれます。 変更箇所の全リストは、Electron v4.0.0 リリースノート を参照してください。

remote モジュールの無効化

セキュリティ上の理由から、remote モジュールを無効化できるようになりました。 このモジュールは BrowserWindowwebview タグに対して無効化できます。

// BrowserWindow
new BrowserWindow({
webPreferences: {
enableRemoteModule: false
}
})

// webview タグ
<webview src="http://www.google.com/" enableremotemodule="false"></webview>

詳細は BrowserWindow<webview> タグ のドキュメントを参照してください。

remote.require() / remote.getGlobal() リクエストのフィルタリング

この機能は、レンダラープロセスや webviewremote モジュールを完全に無効化したくないけれど、remote.require で require され得るモジュールを追加で制御したい場合に便利です。

レンダラープロセス内で remote.require からモジュールが require されると、app モジュールremote-require イベントが発生します。 event (第一引数) の event.preventDefault() を呼び出すと、モジュールをロードしないようにできます。 第 2 引数には require を発生させた WebContents インスタンス が、第 3 引数にはモジュール名が渡されます。 同じイベントが WebContents インスタンスでも発生しますが、この場合はイベントとモジュール名のみが引数です。 どちらの場合でも、event.returnValue に値をセットすることでカスタム値を返すことが出来ます。

// 全ての WebContents からの `remote.require` を制御:
app.on('remote-require', function (event, webContents, requestedModuleName) {
// ...
});

// 特定の WebContents インスタンスからの `remote.require` を制御します。
browserWin.webContents.on(
'remote-require',
function (event, requestedModuleName) {
// ...
}
);

同様に、remote.getGlobal(name) が呼び出されると remote-get-global イベントが発生します。 これは remote-require イベントと同じように動作します。global が返されないように preventDefault() を呼び出したり、event.returnValue でカスタム値を返したりできます。

// 全ての WebContents からの `remote.getGlobal` を制御します。
app.on('remote-get-global', function (event, webContents, requrestedGlobalName) {
// ...
}
);

// 特定の WebContents インスタンスからの `remote.getGlobal` を制御します。
browserWin.webContents.on(
'remote-get-global',
function (event, requestedGlobalName) {
// ...
}
);

詳細は、以下のドキュメントを参照してください。

JavaScript で アプリについて にアクセス

macOS で {role: 'about'} で作成されたメニューアイテムをクリックするのと同じように、app.showAboutPanel() を呼び出すとプログラムから このアプリについて のパネルを表示できるようになりました。 詳しくは showAboutPanel ドキュメント を参照して下さい。

WebContents バックグラウンド抑制の制御

WebContents インスタンスに、ページがバックグラウンドになったときにタイマーやアニメーションの抑制を有効または無効にするメソッド setBackgroundThrottling(allowed) が加わりました。

let win = new BrowserWindow(...)
win.webContents.setBackgroundThrottling(enableBackgroundThrottling)

詳しくは setBackgroundThrottling ドキュメント を参照して下さい。

破壊的変更

macOS 10.9 をサポートしないように

Chromium は macOS 10.9 (OS X Mavericks) をサポートしなくなったので、Electron 4.0 以降でもサポートしません

シングルインスタンスロック

以前は、アプリをシングルインスタンスアプリケーションに (アプリのインスタンスが常に 1 つしか実行されないように) するために、app.makeSingleInstance() メソッドが使用できました。 Electron 4.0 からは、代わりに app.requestSingleInstanceLock() を使用する必要があります。 このメソッドの戻り値は、アプリケーションのこのインスタンスのロックが成功したかどうかを表します。 ロックの取得に失敗した場合は、アプリケーションの別のインスタンスがすでにロックした上で実行していると考えられるため、直ちに終了してください。

requestSingleInstanceLock() の使用例や、さまざまなプラットフォームでの細かい挙動については、app.requestSingleInstanceLock() とその関連メソッド のドキュメントや second-instance イベント を参照してください。

win_delay_load_hook

Windows でネイティブモジュールをビルドするとき、モジュールの binding.gyp 内の win_delay_load_hook 変数は true (これが初期値) にならなければいけません。 このフックが存在しない場合、そのネイティブモジュールは Windows 上ではロードできず、Cannot find module のようなエラーメッセージが表示されます。 詳細は ネイティブモジュールガイドを参照してください

非推奨

以下の破壊的変更が Electron 5.0 で予定されているため、Electron 4.0 で非推奨となります。

Windows で nativeWindowOpen された場合の Node.js インテグレーション無効化

Electron 5.0 からは、nativeWindowOpen オプションで開いた子ウィンドウでは常に Node.js インテグレーションが無効化されます。

webPreferences の既定値

webPreferences オプションを指定して新しいBrowserWindow を作成する場合、以下のように元の webPreferences オプションの省略値は非推奨となり、新しい省略値が採用されます。

プロパティ非推奨の省略値新しい省略値
contextIsolationfalsetrue
nodeIntegrationtruefalse
webviewTagnodeIntegration が設定されていればその値に, さもなくば truefalse

注記: 現在 既知のバグ (#9736) があり、contextIsolation がオンの場合にwebview タグが動作しません。 最新の情報は GitHub の Issue を確認してください!

コンテキストイソレーション、Node インテグレーション、webview タグについての詳細は、Electron セキュリティドキュメント を参照してください。

Electron 4.0 では旧来のデフォルト値を使用しますが、値を明示的に渡さない場合は非推奨の警告が表示されます。 アプリが Electron 5.0 へ対応するように準備するのであれば、これらのオプションに明示的な値を使用してください。 各オプションの詳細については BrowserWindow ドキュメント を参照してください。

webContents.findInPage(text[, options])

medialCapitalAsWordStartwordStart オプションは、上流で削除されたために非推奨となりました。

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

Electron 3.0 の開発時に実施した アプリフィードバックプログラム が成功したので、4.0 の開発でも継続して実施します。 Atlassian、Discord、MS Teams、OpenFin、Slack、Symphony、WhatsApp、その他プログラムメンバーの方々には、4.0 ベータサイクルに参加して頂いたことに多大な感謝の意を表します。 アプリフィードバックプログラムの詳細や今後のベータ版への参加については、当プログラムに関するブログ記事を参照してください

次回予告

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

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

SQLite の脆弱性の修正

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

リモートコード実行の脆弱性 "Magellan" が発見されました。SQLite、Chromium、全バージョンの Electron ベースのソフトウェアに影響します。


影響範囲

Web SQL を使用する Electron アプリケーションが影響を受けます。

緩和策

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

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

これに関する被害報告はありませんが、影響を受けるアプリケーションは緩和策を実施してください。

詳細情報

この脆弱性は Tencent Blade チームによって発見されました。彼らは この脆弱性について論じたブログ記事 を公開しています。

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

Electron の脆弱性を報告する場合は、security@electronjs.org にメールでご連絡お願いします。

Electron アプリフィードバックプログラム

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

Electron はリリースサイクルが高速かつより安定するように取り組んでいます。 実現のため、大規模 Electron アプリのためのアプリフィードバックプログラムを始めました。ベータリリースをテストしてアプリ固有の問題を報告できます。 これは、できるだけ早くアプリケーションを次の安定リリースへアップグレードする、その作業の優先順位付けに役立ちます。

編集(2020-05-21):このプログラムは引退しました。


どんなアプリが参加できますか?

このプログラムに参加するアプリの基準と要件は、以下の項目の通りです。

  • ベータ期間中に 10,000 ユーザー時間以上アプリをテストすること
  • アプリにおける Electron のバグと障害について議論する手続きを毎週行う担当者を 1 人配置すること
  • Electron の 行動規範 の遵守に同意すること
  • 以下の質問に列挙されている下記情報を共有すること

Electron アプリが共有しなければならない情報は何ですか?

  • ベータリリースで実行されたアプリの総ユーザー時間
  • アプリがテストしている Electron のバージョン (4.0.0-beta.3 など)
  • ベータテストされているリリースラインでアプリケーションのアップグレードを妨げるようなバグ

ユーザー時間

すべてが正確なユーザー数を共有できるわけではないことは理解していますが、より良いデータは特定リリースの安定性の判断に役立ちます。 現在、アプリのテストはベータサイクルを通じて 10,000 ユーザー時間まで到達するようにお願いしています。

  • 10 ユーザー時間は、10 人が 1 時間テストする、もしくは 1 人が 10 時間テストするということです。
  • 3.0.0-beta.2 で 5,000 ユーザー時間をテストしてから、3.0.0-beta.5 で 5,000 ユーザー時間をテストする、というようにベータリリース間でテストを分割できます。 多ければ多いほど良いのですが、アプリケーションによっては全ベータリリースをテストできません。
  • CI や QA 時間は合計にカウントされませんが、内部リリースはカウントされます。

私の Electron アプリも参加するべきですか?

あなたのアプリのバグは追跡され、コア Electron チームのレーダーに記録されます。 あなたのフィードバックが、新しいベータ版の動作確認、必要な作業の確認などで Electron チームの役に立ちます。

私のアプリケーションの情報は公開されますか? この情報を見られるのは誰ですか?

いいえ、アプリケーションの情報は一般公開されません。 情報は、アプリフィードバックプログラムと Electron ガバナンス のメンバーのみが閲覧できるプライベート GitHub リポジトリに保管されます。 メンバーは全員 Electron の 行動規範 の遵守に同意しています。

新規申込

現在、新規申込の 数を限定 しています。 もし興味があり、上記の要件を満しているならば、この フォーム に記入してください。

Electron 3.0.0

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

Electron チームは electronjs.org 及び npm install electron@latest から初の Electron 3 安定版が利用できるという発表でワクワクしています! アップグレード、修正、新機能が盛り沢山で、皆さんが何を作るのか待ち遠しいです。 以下に本リリースの詳細をご紹介します。使用したご意見ご感想をお待ちしております。


リリースプロセス

私たちは、v3.0.0 の開発を進めていく中で、プログレッシブベータリリースのフィードバック進捗を定式化することで、安定版リリースの基準をより経験的に定義しようとしました。 v3.0.0 は、アプリフィードバックプログラム に参加してくださった皆様からの、ベータサイクルの初期テストとフィードバックが無ければ不可能だったでしょう。 Atlassian、Atom、Microsoft Teams、Oculus、OpenFin、Slack、Symphony、VS Code、その他のプログラムメンバーに感謝します。 今後のベータへの参加をご希望の方は、info@electronjs.org までご連絡ください。

変更 / 新機能

Chrome v66.0.3359.181、Node v10.2.0、V8 v6.6.6.346.23 など、Electron の重要なツールチェーン部品のいくつかに大きなバージョン上げがありました。

  • [#12656] 新機能: app.isPackaged
  • [#12652] 新機能: app.whenReady()
  • [#13183] 新機能: process.getHeapStatistics()
  • [#12485] 新機能: win.moveTop() でウインドウの Z オーダーを一番上に
  • [#13110] 新機能: TextField と Button の API
  • [#13068] 新機能: netLog API で動的ログ制御
  • [#13539] 新機能: サンドボックスレンダラー内で webview が有効に
  • [#14118] 新機能: fs.readSync が大きいファイルでも動作するように
  • [#14031] 新機能: node の fs のラッパーで fs.realpathSync.nativefs.realpath.native が利用できるように

API の破壊的変更

  • [#12362] 新機能: メニューアイテムの順番を制御できるように更新
  • [#13050] リファクタ: 非推奨 API のドキュメントを削除
  • [#12477] リファクタ: did-get-response-detailsdid-get-redirect-request のイベントを削除
  • [#12655] 新機能: ドラッグ/ドロップ時のナビゲーションをデフォルトで無効に
  • [#12993] 新機能: Node v4.x 以上を electron npm モジュールが要求するように
  • [#12008 #12140 #12503 #12514 #12584 #12596 #12637 #12660 #12696 #12716 #12750 #12787 #12858] リファクタ: NativeWindow
  • [#11968] リファクタ: menu.popup()
  • [#8953] 新機能: ipcRenderer.sendSync の結果送信に JSON を使用しないように
  • [#13039] 新機能: デフォルトで URL に後続するコマンドライン引数を無視するように
  • [#12004] リファクタ: api::Windowapi::BrowserWindow に名称変更
  • [#12679] 新機能: 見た目のズームをデフォルトで無効に
  • [#12408] リファクタ: アプリコマンドの media-play_pausemedia-play-pause に名称変更

macOS

  • [#12093] 新機能: ワークスペース通知をサポート
  • [#12496] 新機能: tray.setIgnoreDoubleClickEvents(ignore) で tray のダブルクリックイベントを無視できるように
  • [#12281] 新機能: macOS でマウス転送機能
  • [#12714] 新機能: 画面をロック/ロック解除のイベント

Windows

  • [#12879] 新機能: screen と screen との座標変換に DIP を追加

注意: このバージョンを動かした後に古いバージョンの Electronに切り替える場合、古いバージョンでのクラッシュを避けるためにユーザーデータのディレクトリを消去する必要があります。 console.log(app.getPath("userData")) を実行してユーザデータのディレクトリを確認するか、ドキュメント を参照して詳細をご確認ください。

バグ修正

  • [#13397] 修正: fs.statSyncNoException が例外を送出する問題
  • [#13476, #13452] 修正: jquery でサイト読み込みをする際のクラッシュ
  • [#14092] 修正: net::ClientSocketHandle デストラクタ内でのクラッシュ
  • [#14453] 修正: フォーカス変更を、次のティックではなくすぐに通知するように

MacOS

  • [#13220] 修正: <input file="type"> のファイルを開くダイアログでバンドルを選択してしまう問題
  • [#12404] 修正: 非同期ダイアログ使用時にメインプロセスをブロックする問題
  • [#12043] 修正: 右クリックメニューのコールバック
  • [#12527] 修正: タッチバーアイテムを再利用時のイベント漏れ
  • [#12352] 修正: tray タイトルのクラッシュ
  • [#12327] 修正: ドラッグ不可領域
  • [#12809] 修正: 開いているメニューの更新を抑止
  • [#13162] 修正: tray アイコンの大きさが負の値を受け付けないように
  • [#13085] 修正: tray タイトルがハイライト時に反転しない
  • [#12196] 修正: enable_run_as_node==false 時の Mac ビルド
  • [#12157] 修正: 鮮明なフレームレスウインドウでの更なる問題
  • [#13326] 修正: app.removeAsDefaultProtocolClient を呼び出した後に mac でのプロトコルを消すように
  • [#13530] 修正: MAS ビルド内での非公開 API の誤用
  • [#13517] 修正: tray.setContextMenu のクラッシュ
  • [#14205] 修正: defaultId を設定している場合でもエスケープを押せばダイアログが閉じるように

Linux

  • [#12507] 修正: オフスクリーンウインドウでの BrowserWindow.focus()

その他注意事項

  • 現在 PDF ビューアは動作しませんが、作業中であり、すぐ動作するようになる予定です。
  • TextFieldButton API は実験的なものなので、デフォルトで無効化されています。
    • これらは enable_view_api ビルドフラグで有効化できます。

次回予告

Electron チームは、最終的に Chromium、Node、V8 の開発ケイデンスと同等で維持するため、より迅速でスムーズなアップグレードプロセスの策定作業を続けています。

GN を使って Electron を構築する

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

Electron は、GN を使用して自身を構築しています。 その理由についてこちらで説明します。


GYP と GN

2013 年、最初に Electron がリリースされたとき、Chromium のビルド構成は GYP で記述されていました。これは "Generate Your Projects" の略です。

2014 年、Chromium プロジェクトは GN ("Generate Ninja") を導入しました。Chromium のビルドファイルは GN に移行され、GYP はソースコードから削除されました。

歴史的に、Electron はメインの Electron コードlibchromiumcontent を分離しています。これは、Chromium の 'content' サブモジュールをラップする Electron の一部です。 Electron は GYP を使用し続けましたが、Chromium の方の libchromiumcontent は GN に切り替えました。

ピッタリ噛まない歯車のように、2 つのビルドシステムの間に摩擦がありました。 互換性の維持にはエラーが発生しやすくなりました。コンパイラフラグと #define を Chromium、Node、V8、Electron 間で細心の注意を払って同期する必要があるからです。

これに対処するため、Electron チームは全てを GN へ移行してきました。 そしてついに、Electron 最後の GYP コード削除の コミットが master に乗りました。

開発者にとっての意義

Electron 自体にコントリビュートしている方は、master もしくは 4.0.0 から Electron をチェックアウトしてビルドするプロセスが 3.0.0 以前と大きく変わります。 詳細は GN ビルド手順 を参照してください。

Electron でアプリを開発している方は、新しい Electron 4.0.0-nightly でのいくつかの小さな変更に気付くかもしれません。しかし、Electron ビルドシステムが変わったことによる影響はおそらくありません。

Electron にとっての意義

GN は GYP より 高速 で、ファイルの可読性が高く保守も容易です。 さらに、単体のビルド構成システムを使用することで、Electron を Chromium の新バージョンへアップグレードするにあたって必要な作業が軽減されるでしょう。

  • Chromium 67 では MSVC サポートを削除し、Windows でも Clang を使用したビルドに切り替えました。そのため、Electron 4.0.0 での開発は既に大幅に支援されています。 GN ビルドでは、Chromium からすべてのコンパイラコマンドを直接継承するため、Windows 用 Clang ビルドを無料で入手できます!

  • また、Electron、Chromium、Node 間で同じビルドの BoringSSL を Electron に使用しやすくなりました。これはもはや 過去の問題 です。

WebPreferences 脆弱性の修正

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

Electron バージョン (3.0.0-beta.6、2.0.7、1.8.7、1.7.15) において、ネストされた子ウィンドウを開くことのできるアプリに影響するリモートコード実行の脆弱性が発見されました。 この脆弱性には CVE 識別子 CVE-2018-15685 が割り当てられています。


影響を受けるプラットフォーム

以下の条件に該当する場合、影響を受けます。

  1. サンドボックス内を含め、なんらかの 外部ユーザコンテンツを埋め込んでいる
  2. XSS 脆弱性のあるユーザの入力受け付けがある

詳細

いずれかのユーザコードが iframe 内で動作している、または iframe を作成できる場合に影響を受けます。 XSS の脆弱性が発生する可能性を考えると、ほとんどのアプリがこのケースに対して脆弱であると想定できます。

ウインドウを nativeWindowOpen: truesandbox: true で開いている場合でも影響を受けます。 この脆弱性はアプリ内に XSS 脆弱性が存在することも条件にありますが、先述のオプションを使用している場合、以下の緩和策のどれかを適用する必要があります。

緩和策

私たちはこの脆弱性の修正を含む新しいバージョンの Electron を公開しました。3.0.0-beta.72.0.81.8.81.7.16 です。 Electron 開発者全員は、アプリをすぐに最新の安定バージョンに更新することを推奨します。

何らかの理由で Electron のバージョンをアップグレードできない場合は、すべての webContents に対して new-window イベントで event.preventDefault() を呼ぶことであなたのアプリを保護できます。 window.open や子ウィンドウを用いないこともまた有効な緩和策です。

mainWindow.webContents.on('new-window', (e) => e.preventDefault());

子ウインドウが孫ウインドウを作ることに依存している場合、3 つ目の緩和策として、最上位ウインドウに以下のコードを使用すると良いでしょう。

const enforceInheritance = (topWebContents) => {
const handle = (webContents) => {
webContents.on(
'new-window',
(event, url, frameName, disposition, options) => {
if (!options.webPreferences) {
options.webPreferences = {};
}
Object.assign(
options.webPreferences,
topWebContents.getLastWebPreferences()
);
if (options.webContents) {
handle(options.webContents);
}
}
);
};
handle(topWebContents);
};

enforceInheritance(mainWindow.webContents);

このコードは、最上位ウインドウの webPreferences がすべての子ウィンドウへ無限に適用されるように手動で強制します。

詳細情報

この脆弱性は Contrast SecurityMatt Austin により発見され、責任を持って Electron プロジェクトへ報告されました。

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

Electron の脆弱性を報告する場合は、security@electronjs.org にメールでご連絡お願いします。

検索

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

Electron のウェブサイトに、APIドキュメント、チュートリアル、Electron 関連の npm パッケージなどを瞬時に検索できる新しい検索エンジンを導入しました。

Electron 検索のスクリーンショット


Electron のような新しい技術やフレームワークを覚えるのは大変なことです。 クイックスタート の段階を過ぎると、ベストプラクティスを学んだり、適切な API を見つけたり、夢のアプリを構築するのに役立つツールを発見したりするのが難しくなっていきます。 Electron のウェブサイトを、より早く、より簡単なアプリ構築のために必要なリソースを探せるようなより良いツールにしたいと考えています。

electronjs.org の任意のページにアクセスすると、ページ上部に新しい検索欄が表示されます。

検索エンジン

ウェブサイトに検索を追加しようと思った当初は、バックエンドに GraphQL を使った独自の検索エンジンを試運転しました。 GraphQL の作業は楽しく、検索エンジンは高パフォーマンスでしたが、この構築は分かりきった作業ではないとすぐに気づきました。 複数語での検索やタイプミス検出のようなものは、正しく動くために多くの作業を必要とします。 車輪を再発明するのではなく、既存の検索ソリューションである Algolia を使用することにしました。

Algolia は、React、Vue、Bootstrap、Yarn、その他多数 の人気オープンソースプロジェクトの間で急速に選ばれる検索エンジンとなったホスト型検索サービスです。

ここでは、Algolia が Electron プロジェクトに適していた機能をいくつか紹介します。

APIドキュメント

時折、何を達成したいか 分かっていても、どのように それを行うかが正確に分からないことがあります。 Electron には 750 以上の API メソッド、イベント、プロパティがあります。 人間は簡単に全部覚えられませんが、コンピュータにとっては得意分野です。 Electron の JSON API ドキュメント を利用して、Algolia にあるすべてのデータをインデックス化し、探している APIを簡単に見つけられます。

ウインドウをサイズ変更してみたいのですか? [resize] で検索して、必要なメソッドに直接ジャンプしましょう。

チュートリアル

Electron では、API ドキュメントを補完するチュートリアルのコレクションが増え続けています。 これで、関連する API ドキュメントと一緒に、特定トピックのチュートリアルもより簡単に見つけられるようになりました。

セキュリティのベストプラクティスをお探しですか? [security] と検索しましょう。

npm パッケージ

npm レジストリには現在 70 万以上のパッケージがあり、必要なパッケージを見つけるのは簡単ではありません。 これらのモジュールをより簡単に探せるように、Electron 向けに特別に作られた 3400 以上のモジュールを集めた electron-npm-packages を作成しました。

Libraries.io の方々は、コード、コミュニティ、ドキュメント、使用状況などのメトリクスの組み合わせに基づいてソフトウェアプロジェクトをスコアリングするシステム、SourceRank を作成しています。 これらのスコアを使って、npm レジストリ内のすべてのモジュールのスコアを含む [sourceranks] モジュールを作成しパッケージの結果をソートしています。

Electron 内蔵の IPC モジュールの代替品をお探しですか? is:package ipc と検索しましょう。

Electron アプリ

Algolia でのデータのインデックスは簡単 なので、electron/apps から既存アプリのリストを追加しました。

[music] や [homebrew] と検索してみてください。

結果のフィルタリング

GitHub の コード検索 を使ったことがある人なら、extension:jsuser:defunkt のようなコロンで区切られたキーバリューフィルタが存在すると気づいているでしょう。 このフィルタリング技術は非常に強力なものであると考えており、Electron の検索に is: キーワードを追加しました。これにより、一種類の結果のみを表示するようにフィルタできます。

キーボードナビゲーション

キーボードショートカットはみんな大好き! キーボードから指を離さずに検索できるようになっています。

  • / 検索欄にフォーカス
  • esc 検索欄にフォーカスしてそれを消去
  • down 次の結果に移動
  • up 前の結果か検索欄に移動
  • enter 結果を開く

また、このキーボード操作を可能にする モジュール もオープンソース化しました。 Algolia InstantSearch 用に設計されていますが、他の検索実装と互換になるように一般化してあります。

フィードバック募集中

新しい検索ツールで何か問題が発生した場合は、それについてお聞かせください!

フィードバックを提出する最善の方法は、GitHub で適切なリポジトリに Issue を提出することです。

謝辞

これらの新しい検索機能を構築してくださった Emily JordanVanessa YuenLibraries.io のスコアを提供してくださった SourceRank 、そして私たちの活動を支援してくださった Algolia のチームに感謝します。 🍹