リリース済みのアプリのApple Notarization Service (Notary Service) 対応

先日、MultiTextConverterについてApple Notarization Service (Notary Service ?) への対応を行いました。この記事は、そのときに行った対応手順などについての記録です。

2019年5月2日にMultiTextConverter v3.6.1を公開しました。MultiTextConverter v3.6.1でEnhanced Runtimeに対応しました。この記事はv3.6.0で対応したときの話です。v3.6.1ではXcode 10にも移行し、Xcode上で全て完結させました。

2019年5月2日 追記

新規アプリでの必須条件

Notarization Serviceに対応して公証を得るためには、必須条件があります。必須条件は以下の通りです。

  • 全実行ファイルがコードサイニングされている
  • アプリケーションとコマンドラインツールは、Hardened Runtimeが有効になっている
  • Developer ID証明書で署名されている
  • コードサイニングの署名にセキュアタイムスタンプが含まれている
  • エンタイトルメントに「com.apple.security.get-task-allow」が含まれていない
  • macOS 10.9 SDK、もしくは、それ以降のSDKとリンクしている

各項目についての詳細は以下のドキュメントに記述されています。

Notarizing Your App Before Distribution

公証の対象

Notarization Serviceで公証の対象になるのは以下のものです。

  • macOSアプリ(コマンドラインなども含めた実行ファイル全てだと思われます)
  • カーネルエクステンション(KEXT)などのアプリ以外のバンドル
  • UDIF形式のディスクイメージ
  • フラットスタイルのインストーラパッケージ

アプリ以外のバンドルも対象になっているので、プラグインやフレームワークなども公証の対象だと思われます。

Xcodeでビルド時に公証出来るのは、Xcodeでビルド出来るものだけなので、ディスクイメージやインストーラなどは、コマンドラインツールを使って手続きします。

MultiTextConverterは、今回は既存のリリース済みアプリをそのまま再ビルドせずに対応させたので、コマンドラインツールを使った方法で行いました。

カーネルエクステンション(KEXT)はすぐに対応が必要

公証が必須になるのは、この記事の時点では将来のOSからですが、KEXTについては例外です。「Notarizing Your App Before Distribution」に以下のように書かれています。

Important

Beginning in macOS 10.14.5, all new or updated kernel extensions and all software from developers new to distributing with Developer ID must be notarized in order to run. In a future version of macOS, notarization will be required by default for all software.

Notarizing Your App Before Distribution – Overview

上記の通り、KEXTについては、macOS 10.14.5から、Developer IDで署名された新しいKEXTと更新されたKEXTについては公証が必須です。

既存のリリース済みソフトウェアでの対応

既存のリリース済みソフトウェアについては、上記の必須条件を満たしていなくても公証を得ることが出来ます。再ビルドや署名のやり直しも必要ありません。流れとしては以下の様になります。

  1. 開発環境の準備
  2. Apple Notary Serviceへのアップロード
  3. チケットの紐付け

開発環境の準備

Xcodeの設定

開発環境はXcode 10以降が必要です。Xcode 10以降をインストールしてから、ターミナルで使用するツールを設定します。(Xcode 10が/Applications/Xcode.appにインストールされている場合)

キーチェーンの設定

スクリプトに平文でパスワードを入れるのはセキュリティ上良くないので、キーチェーンにパスワードを記録させます。ここで使うアカウントとパスワードは、App Store Connectの認証情報です。また、現在は2要素認証が必須になっているので、先にApple IDのアプリパスワードを発行しておく必要があります。ここで使うパスワードはアプリパスワードです。

Apple IDのアプリパスワードの発行はApple IDの管理ページから行います。管理ページは、Appleのトップページの下部のフッター部分に「Apple IDの管理」というテキストでリンクが張られています。

アプリパスワードを発行したら、ターミナルで以下の様にしてキーチェーンにパスワードを追加します。iCloudキーチェーンは使えないので、ローカルキーチェーンに追加する必要があります。

(Account)を使用するアカウントに、(secret-password)をアプリパスワードに置き換えてください。AC_PASSWORDはそのまま入力します。(パスワードではないです)

成功したかどうかは、キーチェーンアプリで確認できます。私の場合は「RK_AC_PASSWORD」という名前を使ったので、上記とは名前が異なりますが、ローカルキーチェンに保存されたことが分かります。

キーチェーンに追加された様子

Apple Notary Serviceへのアップロード

今回はWebに公開しているZipファイルを直接送信しました。Zipファイルの中身は以下の様になっています。

  • MultiTextConverter.app
  • MultiTextConverter説明書.pdf
  • ReleaseNote.md

アップロードは専用のサイトを開くなどではなく、コマンドラインツールで行います。

(bundle_id)は送信アプリのバンドルIDではなく、Notary Serviceで管理するためのバンドルIDのようです。(username)はアカウントに、Archive.zipは送信するアーカイブに置き換えてください。

コマンド実行後、しばらく時間がかかります。何もレスポンスが出ないので不安になりますが、動いているようです。MultiTextConverterの場合は2分くらいたった後、次のようにリクエストIDが返ってきました。

(GUID)の部分は実際には送信リクエスト毎に割り当てられたUUIDが入ってきます。状況の確認をしたいときなどにも使うので、どこかに記録しておいてください。

更に数分経つと、アップルから配布可能になったというメールが届きました。

チケットの紐付け

GateKeeperは公証されているかどうかをオンラインで問い合わせを行います。しかし、オフラインのときや何らかの原因で公証されているかどうかをオンラインで問い合わせ出来なかったときのために、チケットの紐付けを行います。紐付けはアプリパッケージに対して個別に行います。複数あるときはそれぞれ行う必要があるようなので、スクリプト化した方が良いでしょう。

チケットの紐付けが終わったら、紐付け後のアプリをZipで固めて配布ファイルを作ります。

まとめ

既存のリリース済みアプリについては、比較的簡単に公証ができるので、今後新しいOSで古いアプリが動作するようにするために対応した方が良いと思います。

新しいアプリやバージョンアップ時に、公証を得るためには、必須事項に対応する必要があります。大規模なアプリの場合はモジュール構成やインストーラ、サードパーティのライブラリなど、やってみないとどこに技術的な課題があるか分からないので、早めに着手した方が良さそうです。

関連記事

  1. Mac OS X上でUUIDを作成する

  2. Parallelsのキーボードショートカット設定の変更に気が付いた

  3. SwiftでのバッファアクセスはwithUnsafeBytesを使う

  4. Try CLion on the Ubuntu Linux to de…

  5. SSHのクライアント側のセットアップ

  6. Swift 5 + Xcode 10.2 の変更点で気になったところ

最近の著書

最近の記事