web-dev-qa-db-ja.com

iOS / OSXフレームワークの作成：他の開発者に配布する前にコード署名する必要がありますか？

IOSおよびOSXフレームワークの作成方法を学んでいます。 iOSを例に挙げてみましょう。これまでのところ、次の手順が有効です。

  1. -sdk iphonesimulatorおよびBuildアクションを使用したxcodebuildフレームワーク
  2. -sdk iphoneosおよびBuildアクションを使用したxcodebuildフレームワーク
  3. リポツールを使用してユニバーサルバイナリを作成し、lipo -info予想される結果：

ファットファイルのアーキテクチャ：Foo.framework/Foo：i386 x86_64 armv7 arm64

質問は次のとおりです。

  1. 私のフレームワークは、それを使用している開発者によって再署名できることを読みました：「コードサインオンコピー」ですが、そのための前提条件はわかりません。つまり、コードサインステップを追加する必要がありますユニバーサルバイナリを他の開発者に配布する前に署名IDでコード署名しますか？

  2. 前のものが正の場合-「iPhone Distribution：...」アイデンティティまたは「iPhone Developer：...」を使用すれば十分です（iOSプロジェクトの一部である私のフレームワークは、すべての種類の検証、特にApp Store検証に合格します） ）?.

私の答えの背景は、「CodeSignエラー：SDK 'iOS 8.3'の製品タイプ 'Framework'にコード署名が必要です」です。これは、多くのサードパーティフレームワークで見ました Carthage＃235 または「コードオブジェクトはまったく署名されていません」（1つの例： Realm＃1998 で報告した問題。

そのため、私のフレームワークのユーザーは、使用時にコード署名の問題が発生しないことを確認したいと思います。

追伸この質問は、1人の開発者ではなく、フレームワークベンダーである組織に適用するとさらに興味深いものになります。

ioscode-signingios-frameworks
73
Stanislav Pankevich

私は賞金を開きました：「信頼できる、および/または公式の情報源からの回答の描画を探しています。」しかし、それ以来そのようなものを受け取っていません。

@jackslashが提供する答えは正しいですが、それは物語の一部しか伝えていないので、この質問をしているときに見たかった方法で自分で書きたいと思います。

この回答の実際は、2015年7月です。状況が変わる可能性が最も高いです。

まず、フレームワークの正しいコード署名に必要なアクションは、フレームワークの開発者が実行する必要があるステップおよびフレームワークのコンシューマが実行する必要があるステップに分割する必要があると断言しましょう.

TLDR;

OSXフレームワークの場合：開発者は、とにかくコンシューマが再設計するため、コード署名せずにOSXフレームワークを自由に配布できます。

IOSフレームワークの場合：開発者は、いずれにしてもコンシューマが再設計するため、コード署名せずにiOSフレームワークを自由に配布できますが、開発者はXcodeによってiOSデバイス用にビルドするときにフレームワークのコード署名を強制されます。

レーダーのため： 「シミュレータスライスを含むiOSフレームワークはApp Storeに送信できません」 iOSフレームワークのコンシューマーは、「copy_frameworks」や「strip_frameworks」などの特別なスクリプトを実行する必要がありますlipo -removeを使用してiOSフレームワークからシミュレータスライスを取り除き、削除されたフレームワークを再設計します。これは、この時点でコード署名IDがlipo -remove操作の副作用として削除されるためです.

より長い答えが続きます。

この答えは、「信頼できるソースや公式ソースからの引用」ではなく、多くの経験的観察に基づいています。

経験的観察＃1：消費者は、開発者から受け取ったフレームワークを再設計するため、気にしません

Github の有名なオープンソースプロジェクトのバイナリフレームワーク配布は、codesigned ではありません。コマンドcodesign -d -vvvvは、「コードオブジェクトがまったく署名されていない」ことを、私が調査に使用したすべてのバイナリiOSおよびOSXフレームワーク上で提供します。いくつかの例： ReactiveCocoa および Mantle 、 Realm 、 PromiseKit 。

この観察から、これらのフレームワークの作成者は、消費者によってコード署名されることを意図していることが明らかです。つまり、消費者は、Xcodeが提供する「組み込みフレームワーク」ビルドフェーズで「コードサインオン」フラグを使用するか、カスタムシェルを使用する必要があります同じことを手動で行うスクリプト：コンシューマに代わってコード署名フレームワーク。

私は反対の単一の例を見つけませんでした：コード署名IDで配布されるオープンソースフレームワークなので、残りの答えでは、この広く採用されたアプローチを正しいものと仮定しています：フレームワーク開発者は、コード署名IDを含む他の開発者にフレームワークを配布する必要はありません。これは、コンシューマーがとにかく再設計するためです/。

経験的観察＃2 iOSのみに適用され、完全に開発者の懸念事項です

コンシューマーは開発者から受け取ったフレームワークがコード署名されているかどうかを気にしませんが、開発者は、iOSデバイス用にビルドする場合、ビルドプロセスの一部としてiOSフレームワークをコード署名する必要がありますXcodeはビルドしません：CodeSign error: code signing is required for product type 'Framework' in SDK 'iOS 8.1'。引用するには Justin Spahr-Summers ：

OS Xフレームワークはビルド時にコード署名する必要はありません...残念ながら、Xcodeではビルド時にiOSフレームワークにコード署名する必要があります。

これは私の質問＃2に対する非常によく答えます。「iPhone開発者」のアイデンティティはXcodeを揺さぶるのに十分なので、デバイス用のiOSフレームワークを構築できます。 このCarthage＃339のコメント は同じことを言っています。

経験的観察＃3：リポツール

リポツールの特定の動作：フレームワークバイナリに適用すると、コード署名IDを常に再帰的に削除します：lipo -create/-remove codesigned framework ... -> not codesigned framework。

これは、観測＃1のすべての例がまったくコード署名されていない理由の答えである可能性があります：リポ＃1の適用後にコード署名のアイデンティティが吹き飛ばされますが、観測＃1によると、消費者は気にしないので問題ありません。

この観察は、AppStoreに関する次の観察＃4に特に関連しています。

経験的観察＃4：シミュレータースライスを含むiOSフレームワークをApp Storeに送信できません

Realm＃116 および Carthage＃188 で広く議論されており、レーダーが開かれています： rdar：// 19209161 。

これは完全にコンシューマーの懸念です：コンシューマーがアプリケーションに組み込むiOSユニバーサルフレームワークの場合、アプリケーションのビルド時に、アプリケーションがAppStore検証に合格できるように、フレームワークのバイナリからシミュレータースライスを削除する特別なスクリプト（カスタムスクリプト実行フェーズ）を実行する必要があります.

Realmで見つけたバイナリフレームワークの良い例： strip-frameworks.sh 。

lipoを使用して${VALID_ARCHS}以外のアーキテクチャのスライスをすべて削除し、Consumer's identity で再設計します。これが観察＃3の始まりです。フレームワークは、リポ操作のために再設計されます。

Carthageには CopyFrameworks.Swift スクリプトがあり、Consumerに含まれるすべてのフレームワークに対して同じことを行います。Consumerに代わってシミュレータスライスを削除し、フレームワークを再設計します。

また、良い記事があります： Xcodeで動的ライブラリから不要なアーキテクチャを削除する 。

次に、開発者と消費者の両方の観点からiOSとOSXの両方を作成するために必要な手順の概要を説明します。まず簡単なもの：

[〜＃〜] osx [〜＃〜]

開発者：

  1. OSXフレームワークを構築します
  2. 消費者に与える

開発者によるコード署名アクティビティは不要です。

消費者：

  1. 開発者からOSXフレームワークを受け取ります
  2. Frameworks /ディレクトリにフレームワークをコピーし、「コピーオンコードサイン」プロセスの一環として、消費者に代わって自動的にコード署名します。

iOS

開発者：

  1. デバイス用のiOSフレームワークを構築します。 Xcodeでは共同設計が必要です。「iPhone Developer」のIDで十分です。
  2. シミュレータ用のiOSフレームワークを構築します。
  3. 前の2つのユニバーサルiOSフレームワークを生成するリポを使用します。この時点で、1ステップのコード署名IDは失われます。ユニバーサルフレームワークバイナリは「まったく署名されていません」が、「消費者は気にしない」ので問題ありません。
  4. 消費者に与える

消費者：

  1. 開発者からiOSフレームワークを受け取ります
  2. フレームワークをFrameworks /ディレクトリにコピーします（このステップは、ステップ3のスクリプトによっては冗長になる場合があります。）
  3. ビルドプロセスの一部として特別なスクリプトを使用します。このスクリプトは、iOSフレームワークからシミュレータスライスを取り除き、コンシューマーに代わって再設計します。
115
Stanislav Pankevich

Carthageリポジトリのリンクされたスレッドを読むと、比較的簡単に思えます。バイナリフレームワークを配布する場合は、コード署名する必要があります。カルタゴまたはココアポッド経由でソースを配布する場合、これらのツールは別の方法でこれを処理するため、ソースは配布しません。

バイナリフレームワークを配布するときにコード署名する必要があるのは、コード署名なしではXcodeがフレームワークバイナリを生成しないためです。バイナリフレームワークにコード署名しないと、次のエラーが発生します。

CodeSign error: code signing is required for product type 'Framework' in SDK 'iOS 8.1'

あなたが指摘しているように、フレームワークは「コードサインオンコピー」設定で再設計されるため、フレームワークにコード署名するIDは問題ではありません（iPhone DeveloperまたはiPhone Distribution）。これは、フレームワークがアプリケーションにコピーされるときに、フレームワーク消費者の開発者プロファイルからの適切な証明書によってフレームワークが再設計されることを意味します。つまり、フレームワークコンシューマーからの最終的なコード署名のみが表示されるため、App Storeに問題はありません。

最終的には、エキゾチックなビルドプロセスを維持する必要がないため、.frameworkバイナリにコード署名することもできます。Xcodeは署名されたフレームワークのみを出力するため、あまり遠くに移動しないでください。デフォルト。とにかく最終消費者が再署名するため、それは実際には問題ではありません。

19
jackslash

上記のスタニスラフ・パンケビッチの答えは非常に有効で正しい。ただし、Xcode 9.4の時点で、IDEはiOS Cocoa Touch Frameworksのコード署名を無効にするよう求めます。Appleここでは推奨されていません.frameworkにコード署名すること。

これがお役に立てば幸いです。

1
Dino Alves