原文地址：代碼簽名探析

"用戶會感激代碼簽名帶來的好處" – Apple Developer Library: Code Signing Guide

在 iOS 或 OS X 平臺上進行應(yīng)用開發(fā)時亡笑，你所需要使用的 API 大多設(shè)計得簡潔明了。你可以輕易地實現(xiàn)酷炫的動畫效果横朋，便捷地進行應(yīng)用發(fā)布前測試仑乌，或是用 Core Data 將數(shù)據(jù)安全的存儲在本地。但是總有一天叶撒，你會碰上代碼簽名 (code signing) 和配置文件 (provisioning)绝骚，大多數(shù)情況下，這會是你在心里問候某些人祖宗的開始祠够。
如果你已經(jīng)在 iOS 上開發(fā)過應(yīng)用压汪，那么你多半已經(jīng)與代碼簽名或設(shè)備配置文件打過交道了。即使是 OS X 開發(fā)者古瓤，如果你想發(fā)布自己的應(yīng)用到 Mac App Store 上去或者想?yún)⑴c蘋果的開發(fā)者項目止剖，那么也不得不開始為自己的代碼進行簽名腺阳。
大多數(shù)時候代碼簽名看上去像是一個難以理解的神秘黑盒。在這篇文章里我會盡可能揭示盒子內(nèi)部的運作機理穿香。
通常來說亭引，我們無法直接看到代碼簽名的運作過程，它們隱藏在 iOS 系統(tǒng)內(nèi)部和 SDK 之中皮获。但我們可以通過觀察設(shè)置代碼簽名所需工具的運作方式焙蚓，來找出一些線索。除此之外洒宝，我們還可以參考 OS X 上的代碼簽名運作方式购公，畢竟 iOS 和 OS X 系出同源，我們可以從他們的對比之中得到很多有用的信息雁歌。
OS X 上代碼簽名技術(shù)和相應(yīng)的 API 是在 Mac OS X Leopard 10.5 上首次出現(xiàn)的宏浩，這剛好是第一臺 iPhone 發(fā)布的時候。這并非巧合靠瞎，因為在 iOS 上比庄，代碼簽名起到的作用更加重要。iPhone 是在眾多游戲主機之后第一個大規(guī)模出售并且從頭就開始使用代碼簽名的計算平臺乏盐。只有在越獄之后佳窑，iOS 才能運行沒有簽名的代碼。越獄使應(yīng)用可以繞過代碼簽名和沙盒安全機制的全部限制丑勤，這會是一個非常危險的行為华嘹。

證書和密匙

作為一個 iOS 開發(fā)者，在你開發(fā)使用的機器上應(yīng)該已經(jīng)有一個證書法竞，一個公鑰耙厚，以及一個私鑰。這些是代碼簽名機制的核心岔霸。像 SSL 一樣蝶念，代碼簽名也依賴于采用 X.509 標準的公開密鑰加密呜袁。
在 OS X 上迅矛，X.509 的基本組成部分（譯者注：例如證書等）都是由一個叫鑰匙串訪問的工具來進行管理臭挽。打開你開發(fā)機器上的鑰匙串訪問應(yīng)用，選擇類別選項下的“我的證書（My Certificates）”絮爷，你可以看到所有你持有的私鑰相對應(yīng)的證書趴酣。要用一個證書設(shè)置代碼簽名，你必須擁有私鑰坑夯，所以所有你擁有私鑰的證書都會被列在這里岖寞。如果你擁有一個證書的私鑰，你可以展開證書并將它的私鑰顯示出來：

iOS Developer Certificate in the OS X keychain

概括的講隶垮，一個證書是一個公鑰加上許多附加信息藻雪，這些附加信息都是被某個認證機構(gòu)（Certificate Authority 簡稱 CA）進行簽名認證過的，認證這個證書中的信息是準確無誤的狸吞。對于 iOS 開發(fā)來說這個認證機構(gòu)就是蘋果的認證部門 Apple Worldwide Developer Relations CA勉耀。認證的簽名有固定的有效期，這就意味著當前系統(tǒng)時間需要被正確設(shè)置捷绒，因為證書是基于當前時間進行核對瑰排。這也是為什么將系統(tǒng)時間設(shè)定到過去會對 iOS 造成多方面破壞的原因之一。

iOS Developer Certificate in detail

對于 iOS 開發(fā)來說暖侨，一般會有兩個證書：一個帶有前綴iPhone Developer
，另一個帶有前綴iPhone Distribution
崇渗。前者用于使應(yīng)用可以在你的測試設(shè)備上運行字逗，后者是在提交應(yīng)用到 APP store 時用到。一個證書的用途取決于它所包含的內(nèi)部信息宅广，在鑰匙串訪問中雙擊打開一個證書文件葫掉，你可以看到許多詳細條目，拖動到最下面有一條標記著Apple Developer Certificate (Submission)
跟狱， 或者Apple Developer Certificate (Development)
俭厚，具體你會看到哪一種，取決于你所打開的證書是哪一種類型驶臊，iOS 系統(tǒng)會利用這個信息來判斷你的應(yīng)用是運行在開發(fā)模式下還是發(fā)布模式挪挤，并據(jù)此判斷以切換應(yīng)用運行規(guī)則。
為了讓擁有公鑰的證書起作用关翎，我們需要有私鑰扛门。私鑰是你在為組成應(yīng)用的二進制文件進行簽名時派上用場的。沒有私鑰纵寝，你就無法用證書和公鑰對任何東西設(shè)置簽名论寨。
簽名過程本身是由命令行工具codesign
來完成的。如果你在 Xcode 中編譯一個應(yīng)用爽茴，這個應(yīng)用構(gòu)建完成之后會自動調(diào)用codesign
命令進行簽名葬凳，codesign
也正是給你提供了許多格式友好并且有用錯誤信息的那一個工具。你可以在 Xcode 的 project settings 中設(shè)置代碼簽名信息室奏。

Set up of the code signing identity in Xcode project settings

但是在 Xcode 6 的 project settings 中出現(xiàn)了設(shè)置配置文件的選項樊诺。如果你選擇了某一個配置文件，你必須選擇這個配置文件的證書中所包含的公鑰所對應(yīng)的那個密匙對音同，或者你可以選擇讓 Xcode 自動完成正確的設(shè)置词爬。關(guān)于這方面我們稍后再詳細說明，首先還是回到代碼簽名权均。

一個已簽名應(yīng)用的組成

一個已簽名的可執(zhí)行文件的簽名包含在 Mach-O 二進制文件格式中顿膨；對于例如腳本這樣的非 Mach-O 可執(zhí)行文件，就存放在該文件系統(tǒng)的的擴展屬性中叽赊。這種做法使得在 OS X 和 iOS 上的任何可執(zhí)行二進制文件都可以被設(shè)置簽名：不論是動態(tài)庫恋沃，命令行工具，還是 .app 后綴的程序包必指。這也意味著設(shè)置簽名的過程實際上會改動可執(zhí)行文件的文件內(nèi)容囊咏，將簽名數(shù)據(jù)寫入二進制文件中。
如果你擁有一個證書和它的私鑰塔橡，那么用codesign
來設(shè)置簽名非常簡單梅割，我們現(xiàn)在嘗試用下面列出的這個證書來為Example.app
設(shè)置簽名：
$ codesign -s 'iPhone Developer: Thomas Kollbach (7TPNXN7G6K)' Example.app

如果你想為某一個 app 程序包重新設(shè)置簽名，那么這個工具就很有用了谱邪。為了重新設(shè)置簽名炮捧，你必須帶上-f
參數(shù)，有了這個參數(shù)惦银，codesign
會用你選擇的簽名替換掉已經(jīng)存在的那一個：
$ codesign -f -s 'iPhone Developer: Thomas Kollbach (7TPNXN7G6K)' Example.app

codesign
還可以為你提供有關(guān)一個可執(zhí)行文件簽名狀態(tài)的信息咆课，這些信息在出現(xiàn)不明錯誤時會提供巨大的幫助。舉例來說扯俱，$ codesign -vv -d Example.app
會列出一些有關(guān)Example.app
的簽名信息：
Executable=/Users/toto/Library/Developer/Xcode/DerivedData/Example-cfsbhbvmswdivqhekxfykvkpngkg/Build/Products/Debug-iphoneos/Example.app/Example Identifier=ch.kollba.example Format=bundle with Mach-O thin (arm64) CodeDirectory v=20200 size=26663 flags=0x0(none) hashes=1324+5 location=embedded Signature size=4336 Authority=iPhone Developer: Thomas Kollbach (7TPNXN7G6K) Authority=Apple Worldwide Developer Relations Certification Authority Authority=Apple Root CA Signed Time=29.09.2014 22:29:07 Info.plist entries=33 TeamIdentifier=DZM8538E3E Sealed Resources version=2 rules=4 files=120 Internal requirements count=1 size=184

你需要查看的第一件事是以Authority
開頭的那三行书蚪。這三行告訴你到底是哪一個證書為這個 app 設(shè)置了簽名。在這里當然是我的證書迅栅，iPhone Developer: Thomas Kollbach (7TPNXN7G6K)
殊校。我的這個證書則是被證書Apple Worldwide Developer Relations Certification Authority
設(shè)置了簽名的，依此類推這個證書則是被證書Apple Root CA
設(shè)置了簽名读存。
在Format
中也包含了一些關(guān)于代碼的信息：Example.app
并不單單是一個可執(zhí)行文件为流，它是一個程序包呕屎，其中包含了一個arm64
二進制文件。從Executable
中的路徑信息你可以看出敬察，這是一個以測試為目的的打包秀睛，所以是一個Mach-O thin
的二進制文件。
在一堆診斷信息中還包含了兩個非常有趣的條目莲祸。Identifier
是我在 Xcode 中設(shè)置的 bundle identifier蹂安。TeamIdentifier
用于標識我的工作組（系統(tǒng)會用這個來判斷應(yīng)用是否是由同一個開發(fā)者發(fā)布）。此外用于發(fā)布應(yīng)用的證書中也包含這種標識锐帜，這種標識在區(qū)分同一名稱下的不同證書時非常有用田盈。
現(xiàn)在這個二進制文件已經(jīng)用證書設(shè)置好簽名。就像中世紀人用蠟來封印信封一樣缴阎，簽名就這樣封印了這個應(yīng)用允瞧。下面我們來檢查一下封印是否完好：
$ codesign --verify Example.app$

就像大多數(shù) UNIX 工具一樣，沒有任何輸出代表簽名是完好的药蜻。那么我下面破壞這個封印瓷式，只要修改一下這個二進制文件：
$ echo 'lol' >> Example.app/Example$ codesign --verify Example.appExample.app: main executable failed strict validation

修改已經(jīng)簽名的應(yīng)用會破壞封印，從命令行輸出我們可以看到代碼簽名正如我們所預(yù)期一樣起到了作用语泽。

程序包和其他資源文件

對于命令行工具和腳本來說，只是一個可執(zhí)行文件被設(shè)置簽名视卢，但是 iOS 和 OS X 的應(yīng)用和框架則是包含了它們所需要的資源在其中的踱卵。這些資源包括圖片和不同的語言文件，資源中也包括很重要的應(yīng)用組成部分例如 XIB/NIB 文件据过，存檔文件(archives)惋砂，甚至是證書文件。所以為一個程序包設(shè)置簽名時绳锅，這個包中的所有資源文件也都會被設(shè)置簽名西饵。
為了達到為所有文件設(shè)置簽名的目的，簽名的過程中會在程序包中新建一個叫做_CodeSignatue/CodeResources
的文件鳞芙，這個文件中存儲了被簽名的程序包中所有文件的簽名眷柔。你可以自己去查看這個簽名列表文件，它僅僅是一個 plist 格式文件原朝。
這個列表文件中不光包含了文件和它們的簽名的列表驯嘱，還包含了一系列規(guī)則，這些規(guī)則決定了哪些資源文件應(yīng)當被設(shè)置簽名喳坠。伴隨 OS X 10.10 DP 5 和 10.9.5 版本的發(fā)布鞠评，蘋果改變了代碼簽名的格式，也改變了有關(guān)資源的規(guī)則壕鹉。如果你使用10.9.5或者更高版本的codesign
工具剃幌，在CodeResources
文件中會有4個不同區(qū)域聋涨，其中的rules
和files
是為老版本準備的，而files2
和rules2
是為新的第二版的代碼簽名準備的负乡。最主要的區(qū)別是在新版本中你無法再將某些資源文件排除在代碼簽名之外牍白，在過去你是可以的，只要在被設(shè)置簽名的程序包中添加一個名為ResourceRules.plist
的文件敬鬓，這個文件會規(guī)定哪些資源文件在檢查代碼簽名是否完好時應(yīng)該被忽略淹朋。但是在新版本的代碼簽名中，這種做法不再有效钉答。所有的代碼文件和資源文件都必須設(shè)置簽名础芍，不再可以有例外。在新版本的代碼簽名規(guī)定中数尿，一個程序包中的可執(zhí)行程序包仑性，例如擴展 (extension)，是一個獨立的需要設(shè)置簽名的個體右蹦，在檢查簽名是否完整時應(yīng)當被單獨對待诊杆。

授權(quán)機制 (Entitlements) 和配置文件 (Provisioning)

到目前為止，我們都假設(shè)所有的證書起到的作用都是一樣的何陆，并且假設(shè)如果我們有了一個有效的證書代碼簽名也就相應(yīng)的有效晨汹。然而這當然不是唯一的規(guī)則。操作系統(tǒng)有許多標準來檢測你的代碼是否允許運行贷盲。
這些標準并不是一成不變的淘这。舉例來說，在 OS X 上一個應(yīng)用是否允許被開啟是由 Gatekeeper 的選項決定的巩剖，你可以在系統(tǒng)設(shè)置的安全選項中改變選項铝穷。在 Gatekeeper 選項中選擇 “受信任的開發(fā)者或者來自 Mac App Store” 會要求被打開的應(yīng)用必須被證書簽名，可以是 Mac App Store 開發(fā)者的應(yīng)用發(fā)布證書也可以是開發(fā)者 ID 證書佳魔。這些選項是由一個系統(tǒng)工具spctl
來管理的曙聂，它管理著系統(tǒng)的所有安全評估策略。
在 iOS 上規(guī)則是不一樣的鞠鲜，無論是用戶還是開發(fā)者都不能改變應(yīng)用開啟策略宁脊，你必須有一個開發(fā)者帳號或者應(yīng)用發(fā)布證書才能讓應(yīng)用運行在 iOS 系統(tǒng)上。
即使你可以讓應(yīng)用運行起來镊尺，在 iOS 上你的應(yīng)用能做什么依然是受限制的朦佩。這些限制是沙盒管理的。沙盒和代碼簽名機制是不同的庐氮，這很重要语稠。代碼簽名保證了這個應(yīng)用里所包含的內(nèi)容正如它所說的那樣不多不少，而沙盒則是限制了應(yīng)用訪問系統(tǒng)的資源。這兩種技術(shù)是相互合作來發(fā)揮作用的仙畦，它們都能阻止你的應(yīng)用運行输涕，也都能在 Xcode 中引起奇怪的問題。但是在日常開發(fā)過程中慨畸，沙盒可能會更經(jīng)常引起問題莱坎。沙盒機制在什么時候會引起問題呢，大多數(shù)情況下都是由于一個叫做授權(quán)的機制決定的寸士。

授權(quán)機制

授權(quán)機制決定了哪些系統(tǒng)資源在什么情況下允許被一個應(yīng)用使用檐什。簡單的說它就是一個沙盒的配置列表，上面列出了哪些行為被允許弱卡，哪些會被拒絕乃正。
很可能你已經(jīng)猜到授權(quán)機制也是按照 plist 文件格式來列出的。Xcode 會將這個文件作為--entitlements
參數(shù)的內(nèi)容傳給codesign
婶博，這個文件內(nèi)部格式如下：
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>application-identifier</key> <string>7TPNXN7G6K.ch.kollba.example</string> <key>aps-environment</key> <string>development</string> <key>com.apple.developer.team-identifier</key> <string>7TPNXN7G6K</string> <key>com.apple.developer.ubiquity-container-identifiers</key> <array> <string>7TPNXN7G6K.ch.kollba.example</string> </array> <key>com.apple.developer.ubiquity-kvstore-identifier</key> <string>7TPNXN7G6K.ch.kollba.example</string> <key>com.apple.security.application-groups</key> <array> <string>group.ch.kollba.example</string> </array> <key>get-task-allow</key> <true/></dict> </plist>

在 Xcode 的 Capabilities 選項卡下選擇一些選項之后瓮具，Xcode 就會生成這樣一段 XML。 Xcode 會自動生成一個.entitlements
文件凡人，然后在需要的時候往里面添加條目名党。當構(gòu)建整個應(yīng)用時，這個文件也會提交給codesign
作為應(yīng)用所需要擁有哪些授權(quán)的參考挠轴。這些授權(quán)信息必須都在開發(fā)者中心的 App ID 中啟用传睹，并且包含在配置文件中，稍后我們會詳細討論這一點岸晦。在構(gòu)建應(yīng)用時需要使用的授權(quán)文件可以在 Xcode build setting 中的 code signing entitlements 中設(shè)置蒋歌。
在這個應(yīng)用中我啟用了 iCloud 鍵值對存儲 (key-value storage) (com.apple.developer.ubiquity-kvstore-identifier
) ，以及 iCloud 文檔存儲 (com.apple.developer.ubiquity-container-identifiers
)委煤。另外我還將應(yīng)用添加進了一個 App Group (比如說為了與擴展 (extensions) 共享數(shù)據(jù)，com.apple.security.application-groups
)修档， 最后開啟了推送功能 (aps-environment
)碧绞。這是一個開發(fā)版本，我會有將它連接到調(diào)試器的需求吱窝，這就需要將get-task-allow
設(shè)為true
讥邻。另外，app id院峡，也就是 bundle id 加上開發(fā)者 id兴使，也被單獨列出來了。
當然你并不能隨心所欲的取得授權(quán)照激，你的應(yīng)用能否得到某一項授權(quán)是有特定的規(guī)定的发魄。舉例來說，當get-task-allow
被設(shè)定為ture
時，應(yīng)用只能在用于開發(fā)的證書簽名下運行励幼。你被允許使用的推送環(huán)境 (aps-environment) 也存在類似的限制汰寓。
根據(jù)操作系統(tǒng)版本的不同我們可選的授權(quán)項目是不一樣的，所以很難有一份列表可以詳盡地列出所有條目苹粟。至少在文檔 Adding Capabilities 中提到的所有功能都是需要經(jīng)過授權(quán)的有滑。
授權(quán)信息會被包含在應(yīng)用的簽名信息中。如果你在這方面遇到了問題嵌削，可以嘗試查看簽名信息中具體包含了什么授權(quán)信息：$ codesign -d --entitlements - Example.app
會列出一個和前面的很像的 XML 格式的屬性列表毛好。你可以將這個文件的內(nèi)容添加進一個腳本，每次構(gòu)建應(yīng)用時用腳本檢查是否包含了推送服務(wù)的授權(quán)信息苛秕，以此確保推送服務(wù)工作正常肌访。在這里推送服務(wù)只是一個例子，你使用的服務(wù)越多想帅，這樣的時候都添加推送通知的授權(quán)场靴，以保證可以注冊推送通知。在新版本的 Xcode 6 之后港准，授權(quán)信息列表會以Example.app.xcent
這樣的名字的文件形式包含在應(yīng)用包中旨剥。在我看來，這么做是為了在出現(xiàn)配置錯誤時提供更加有用的錯誤信息浅缸。

配置文件

在整個代碼簽名和沙盒機制中有一個組成部分將簽名轨帜，授權(quán)和沙盒聯(lián)系了起來，那就是配置文件 (provisioning profiles)衩椒。
每一個 iOS 開發(fā)者可能都花費過相當?shù)臅r間研究如何設(shè)置配置文件蚌父，這個環(huán)節(jié)也正是會經(jīng)常出問題的地方。
一個配置文件中存放了系統(tǒng)用于判斷你的應(yīng)用是否允許運行的信息毛萌，這就意味著如果你的配置文件有問題苟弛，修復(fù)起來會相當煩人。
一個配置文件是一組信息的集合阁将，這組信息決定了某一個應(yīng)用是否能夠在某一個特定的設(shè)備上運行膏秫。配置文件可以用于讓應(yīng)用在你的開發(fā)設(shè)備上可以被運行和調(diào)試，也可以用于內(nèi)部測試 (ad-hoc) 或者企業(yè)級應(yīng)用的發(fā)布做盅。Xcode 會將你在 project setting 中選擇的配置文件打包進應(yīng)用缤削。前面提到了，選擇配置文件是 Xcode 6 才提供的功能吹榴，在 Xcode 5 或更早版本中亭敢，配置文件是 Xcode 根據(jù)你選擇的簽名證書來選擇的。事實上同一個證書可以擁有多個不同的配置文件图筹，因此讓 Xcode 自行選擇可能存在一些不確定性帅刀，最好的方式是你自主去選擇，在 Xcode 6 中終于提供了這個功能。

Project settings for selecting the provisioning profile

我們下面來仔細研究一下配置文件劝篷。如果你要在自己的機器上找到配置文件哨鸭，在這個目錄下~/Library/MobileDevice/Provisioning Profiles
。Xcode 將從開發(fā)者中心下載的全部配置文件都放在了這里娇妓。
不要驚訝像鸡，配置文件并不是一個 plist 文件，它是一個根據(jù)密碼訊息語法 (Cryptographic Message Syntax) 加密的文件（下文中會簡稱 CMS哈恰，但不要用這個簡寫 Google只估，這不是一個很好的關(guān)鍵字）。如果你處理過 S/MIME 郵件或者證書你會對這種加密比較熟悉着绷，詳細信息可以查看互聯(lián)網(wǎng)工程任務(wù)組 (IETF) 制定的 RFC 3852蛔钙。
采用 CMS 格式進行加密使得配置文件可以被設(shè)置簽名，所以在蘋果給你這個文件之后文件就不能被改變了荠医。配置文件的簽名和應(yīng)用的簽名不是一回事吁脱，它是由蘋果直接在開發(fā)者中心 (developer portal) 中設(shè)置好了的。
某些版本的 OpenSSL 可以讀取這種格式彬向，但是 OS X 自帶那個版本并不行兼贡。幸運的是命令行工具security
也可以解碼這個 CMS 格式，那么我們就用security
來看看一個.mobileprovision
文件內(nèi)部是什么樣子：
$ security cms -D -i example.mobileprovision

這個命令會輸出簽名信息中的內(nèi)容娃胆，如果你親自試一下遍希，接下來你會得到一個 XML 格式的 plist 文件內(nèi)容輸出。
這個列表中的內(nèi)容是 iOS 用于判斷你的應(yīng)用是否能運行在某個設(shè)備上真正需要的配置信息里烦，每一個配置文件都有它自己的UUID
凿蒜。Xcode 會用這個UUID
來作為標識，記錄你在 build settings 中選擇了哪一個配置文件胁黑。
首先來看DeveloperCertificates
這項废封，這一項是一個列表，包含了可以為使用這個配置文件的應(yīng)用簽名的所有證書丧蘸。如果你用了一個不在這個列表中的證書進行簽名虱饿，無論這個證書是否有效，這個應(yīng)用都無法運行触趴。所有的證書都是基于 Base64 編碼符合 PEM (Privacy Enhanced Mail, RFC 1848) 格式的。要查看一個證書的詳細內(nèi)容渴肉，將編碼過的文件內(nèi)容復(fù)制粘貼到一個文件中去冗懦，像下面這樣：
-----BEGIN CERTIFICATE-----MIIFnjCCBIagAwIBAgIIE/IgVItTuH4wDQYJKoZIhvcNAQEFBQAwgZYxCzA… -----END CERTIFICATE-----`

然后讓 OpenSSL 來處理openssl x509 -text -in file.pem
。
回到配置文件中繼續(xù)往下看仇祭，你可能會注意到在Entitlements
一項中包含了你的應(yīng)用的所有授權(quán)信息披蕉，鍵值就和之前在授權(quán)那節(jié)看到的一模一樣。
這些授權(quán)信息是你在開發(fā)者中心下載配置文件時在 App ID 中設(shè)置的，理想的情況下没讲，這個文件應(yīng)該和 Xcode 為應(yīng)用設(shè)置簽名時使用的那一個同步眯娱，但這種同步并不能得到保證。這個文件的不一致是比較難發(fā)現(xiàn)的問題之一爬凑。
舉例來說徙缴，如果你在 Xcode 中添加了 iCloud 鍵值對存儲授權(quán) (com.apple.developer.ubiquity-kvstore-identifier
)，但是沒有更新嘁信，重新設(shè)置并下載新的配置文件于样，舊的配置文件規(guī)定你的應(yīng)用并沒有這一項授權(quán)。那么如果你的應(yīng)用使用了這個功能潘靖，iOS 就會拒絕你的應(yīng)用運行穿剖。這也是當你在開發(fā)者中心編輯了應(yīng)用的授權(quán)，對應(yīng)的配置文件會被標記為無效的原因卦溢。
如果你打開的是一個用于開發(fā)測試的證書糊余，你會看到一項ProvisionedDevices
，在這一項里包含了所有可以用于測試的設(shè)備列表单寂。因為配置文件需要被蘋果簽名贬芥，所以每次你添加了新的設(shè)備進去就要重新下載新的配置文件。

小結(jié)

代碼簽名和配置文件這一套大概是一個 iOS 開發(fā)者必須處理的僅次于編碼的最復(fù)雜的問題之一凄贩。與在 Mac 或 PC 上直接的編譯運行你的代碼不同誓军，處理這些問題會是非常不同的經(jīng)歷。
雖然了解每一個部分是怎么運作的很有幫助疲扎，但是要控制好所有這些設(shè)置和工具其實是一件很消耗時間的事情昵时，特別是在一個開發(fā)團隊中，到處發(fā)送證書和配置文件顯然很不方便椒丧。雖然蘋果在最近幾次發(fā)布的 Xcode 中都嘗試改善壹甥，但是我不是很確定每一項改動都起到了好的作用。處理代碼簽名是每個開發(fā)者必過的大坑壶熏。
雖然處理代碼簽名對于開發(fā)者來說非常繁瑣句柠，但不可否認正是它使得 iOS 對于用戶來說是一個非常安全的操作系統(tǒng)。如果你注意安全相關(guān)的新聞棒假，每一次出現(xiàn)號稱能在 iOS 上運行的木馬或者惡意軟件溯职，例如不怎么出名的 FinFisher，仔細看看詳細說明帽哑，都會寫明 “需要越獄”谜酒。說實話我還沒見過面向 iOS 的不需要越獄的病毒或者木馬。
所以為代碼簽名和配置文件進行的這些麻煩設(shè)置并不是徒勞無功妻枕。