インストールの安全性

インストールそのものを自分で担っているからこそ、こうしたチェックが可能になっています。どれも、あるソフトウェアが別のソフトウェアを Mac 上で置き換えるときに起こり得る問題への対策です。

実行中のアプリを強制終了しない

インストーラが何かを強制終了することは決してありません。更新したアプリを再起動するのは別のステップで、デフォルトでオンになっていますが設定でオフに切り替えられます。実行される際も、終了させる処理はただの terminate() です。アプリは自分自身の保存確認を表示でき、終了を拒否することもできます。拒否したアプリはそのまま起動を続け、行には 再起動 ボタンが残るので、強制終了によって未保存の作業が失われることはありません。

知っておくとよいこと：再起動は新しいバージョンがすでにディスク上にあるあとで行われます。つまり終了を断ると、更新済みのバンドルのすぐそばで、まだ旧コードを実行しているプロセスが動き続けることになります —— 自分でアプリを再度起動するまでその状態が続きます。それが行の「再起動」ボタンの意味です。

何かを入れ替える前の5つのチェック

EdDSA —— アプリ自身が公開鍵を提供している場合です。ベンダーによっては署名なしのフィードを出していますが、それだけで拒否されるわけではなく、残りのチェックを自力で通過すれば構いません。鍵を公開しているアプリは有効な署名を提示する必要があります —— 下記で説明する意図的な例外が一つだけあります。

その上で、更新元にかかわらず、ダウンロードしたバンドルに対して次の4つのチェックが行われます。

• Developer ID 署名 —— 厳密に、かつすべての階層で検証されます。すべてのアーキテクチャ、そしてネストされたコードも対象で、外側のバンドルだけではありません。
• Team ID —— 置き換え対象のアプリと一致している必要があります。
• Bundle identifier —— Info.plist ではなく署名から取得するため、書き換えられた plist ではこのチェックをすり抜けられません。
• 実行可能なアーキテクチャ —— 実際の Mach-O スライスから読み取ります。この Mac では起動できないビルドは、インストールして壊れたまま残すのではなく、拒否されます。

異なる開発者に行き着くダウンロードは、インストールされず拒否されます。

例外はこうです：ベンダーが移行用ビルドを出さないまま署名鍵をローテーションすると、旧い鍵ではそのベンダーが公開するものを何も検証できなくなります。そのアプリを永久に取り残すのではなく、無効な EdDSA 署名はその場で拒否せず保留され、残り4つのチェックが通り、かつダウンロードしたバンドルがそのフィードを検証できる新しい鍵を含んでいれば、インストールが続行されることがあります。この場合、信頼を担保しているのは Developer ID と Team ID のゲートです。

メジャーバージョンへのアップグレードは確認が必要

新しいメジャーバージョンへの移行は、ワンクリックのボタンではなく警告の背後に置かれます。商用アプリの場合、新しいライセンスが必要になることがあるからです。判断するのはあなたで、DuoUpdater が手軽さでその判断を代わりに済ませることはありません。

インストール直前にもう一度すべてを再確認する

1時間開きっぱなしのリストは古くなっています。入れ替えの直前にもう一度チェックが走るため、その間に別の何かによってすでに更新されていたアプリに対して、無駄なインストールが実行されることはありません。

ロールバック用バックアップ

置き換えられるバンドルは保存されており、元に戻すことができます。duo backups はロールバックポイントをコマンドラインから一覧表示し、アプリ側にも同じものが用意されています。

再起動の検出

あるアプリがディスク上では更新済みなのに、まだ古いビルドを実行している場合 —— 推測ではなく LaunchServices を介した比較によって判定されます —— そのアプリは最新の状態として報告される代わりに 再起動 アクションとともに表示されます。ディスク上のバージョンと実行中のバージョンは別々の事実であり、行はそのどちらが古いのかを教えてくれます。