Code Signing for macOS/ru: what changed

Revision 2 to 3. Removed lines have a minus sign; added lines have a plus sign.

Old	New		Line
1	1		> Note: Для требований нотариального заверения Apple для расширений ядра и приложений, начиная с Mojave 10.14.5 (для расширений ядра от 7 апреля 2019 г. и для разработчиков, чье первое использование их сертификата подписи кода произошло с 7 апреля 2019 г.) и для всего программного обеспечения, начиная с Catalina 10.15 и выше, которое не распространяется через App Store, см. [[Notarization for macOS 10.14.5+/ru\|Нотариальное заверение для macOS 10.14.5+]]
2	2
3	3		## Предисловие
4	4
5	5		[[Code signing]] (подписание кода) обеспечивает как подлинность, так и целостность исполняемых файлов, загруженных из глобальных сетей, таких как Интернет. Приведенное ниже обсуждение в равной степени относится как к распространению в App Store, так и к распространению вне App Store.
6	6
7	7		Подписание кода требуется в [[Portal:iOS\|iOS]]. В [[Portal:Mac\|macOS]] и более поздних версиях он позволяет открывать программы, загруженные из Интернета, без каких-либо предупреждений (если они подписаны сертификатом, выданным Apple), и требуется при использовании определенных функций (например, API-интерфейсы, используемые отладчиками; обратите внимание, что в этом случае достаточно самозаверяющего сертификата, помеченного как «доверенный»). Эту функцию выполняет программное обеспечение Apple Gatekeeper.
8	8
9	9		## Процесс развития Gatekeeper
10	10
11	11		Gatekeeper (Привратник), впервые представленный в Mountain Lion (10.8, 2012 г.), представляет собой функцию безопасности Mac, предназначенную для защиты компьютеров Apple от вредоносного программного обеспечения. Привратник проверяет приложения по списку приложений, которые Apple одобрила для своего App Store или код которых был подписан разработчиками, имеющими сертификаты, выпущенные Apple, если приложение не предлагается через магазин приложений. Он не выполняет никаких проверок безопасности сам по себе, за исключением того, что приложение не было изменено с момента его подписания разработчиком, и не дает никаких гарантий в отношении разработчика, кроме того, что он платит Apple 99 долларов США в год (он же "Идентифицированный разработчик").
12	12
13	13		Первоначальные параметры Gatekeeper, представленные в Mountain Lion, доступ к которым можно получить из настроек "Безопасность" "Конфиденциальность" \> "Общее", были следующими:
14	14
15	15		- App Store
16	16		- App Store и признанные разработчики
17	17		- Anywhere (кто угодно)
18	18
19	19		Выбрав опцию Anywhere, пользователь когда-то мог полностью отключить Gatekeeper. Настройка по умолчанию разрешала запуск приложений только из App Store или от разработчика, подписавшего свое приложение с помощью сертификата, выданного Apple.
20	20
21	21		Когда в 2016 году была выпущена macOS Sierra, Apple внесла несколько важных изменений в Gatekeeper и ограничила параметры Gatekeeper следующим образом:
22	22
23	23		- App Store
24	24		- App Store и признанные разработчики
25	25
26	26		Однако вы можете восстановить отсутствующую опцию Gatekeeper Anywhere в настройках, открыв терминал и выполнив команду:
27	27
28	28		`$ sudo spctl --master-disable`
29	29
30	30		которая по-прежнему работает до macOS Catalina включительно. Лучшей, как и более безопасной, альтернативой было вместо этого обойти Gatekeeper, открыв приложение из контекстного меню по клику правой кнопки мыши, или по клику с зажатой `Ctrl`. Это по-прежнему вызывало бы диалоговое окно предупреждения, но теперь оно бы содержало кнопку Открыть для успешного запуска приложения. Этот метод обхода Gatekeeper по-прежнему работает в macOS Catalina, за исключением того, что в Catalina вам нужно запустить приложение во второй раз, удерживая `Ctrl` или щелкнув правой кнопкой мыши, чтобы успешно обойти Gatekeeper - при первом запуске приложения Gatekeeper не может быть обойден независимо от того, удерживаете ли вы `Ctrl` или щелкаете правой кнопкой мыши или нет.
31	31
32	32		### Big Sur и более новые ОС на процессорах Apple M1 ARM64
33	33
34	34		И тогда Apple изменила правила игры.
35	35
36	36		Когда Big Sur запущена на процессоре Apple M1 (ARM64), весь нативный код ARM64 должен быть подписан, иначе операционная система не позволит его выполнение; и пользователи не могут обойти это новое требование Gatekeeper. Разработчики могут обойти его, выполнив следующую команду в окне терминала Applications \> Utilities \> Terminal:
37	37
38	38		`spctl developer-mode enable-terminal`
39	39
40	40		и затем перейдя в System Preferences \> Security & Privacy \> Privacy, прокрутив вниз до записи "Developer Tools" (Инструменты разработчика), выполнив аутентификацию и установив флажок рядом с Terminal.
41	41
42	42		Исполняемые файлы Intel, запущенные под Big Sur на процессоре Apple M1 через Rosetta 2, по-прежнему могут быть запущены, даже если они не подписаны, кликом ЛКМ с зажатой `Ctrl` или кликом ПКМ мыши для обхода Gatekeeper.
43	43
44	44		Больше подробностей см.: [[macOS Big Sur changes for developers\|Big Sur изменения для разработчиков: Подписывание кода - Intel в сравнении с M1]].
45	45
46	46		## Диалоговые окна Gatekeeper
47	47
48		-	<File:load> security warning dmg leopard en.png\\|Простое предупреждение после открытия загруженного приложения в Leopard. <File:load> security warning dmg mavericks en.png\\|Настройки по умолчанию более строгие в Mavericks, где они предотвращают запуск загруженных неподписанных приложений с помощью двойного щелчка мыши. <File:load> security warning mavericks context en.png\\|Если приложение запускается через контекстное меню в Mavericks, отображается простое предупреждение, аналогичное тому, что было в более ранних версиях. <File:simple> load security warning mavericks en.png\\|Gatekeeper показывает упрощенное предупреждение, если приложение с подписанным кодом было загружено и запущено в первый раз. При последующих запусках программа запускается сразу. <File:codesigning.png%7CСхема> подписания кода программы, написанной с помощью Lazarus и Free Pascal
	48	+	![](/wiki-images/2/26/Load_security_warning_dmg_leopard_en.png)
	49	+
	50	+	Простое предупреждение после открытия загруженного приложения в Leopard.
	51	+
	52	+	![](/wiki-images/3/31/Load_security_warning_dmg_mavericks_en.png)
	53	+
	54	+	Настройки по умолчанию более строгие в Mavericks, где они предотвращают запуск загруженных неподписанных приложений с помощью двойного щелчка мыши.
	55	+
	56	+	![](/wiki-images/2/20/Load_security_warning_mavericks_context_en.png)
	57	+
	58	+	Если приложение запускается через контекстное меню в Mavericks, отображается простое предупреждение, аналогичное тому, что было в более ранних версиях.
	59	+
	60	+	![](/wiki-images/c/c3/Simple_load_security_warning_mavericks_en.png)
	61	+
	62	+	Gatekeeper показывает упрощенное предупреждение, если приложение с подписанным кодом было загружено и запущено в первый раз. При последующих запусках программа запускается сразу.
	63	+
	64	+	![](/wiki-images/1/15/Codesigning.png)
	65	+
	66	+	Схема подписания кода программы, написанной с помощью Lazarus и Free Pascal
49	67
50	68		## Обзор
51	69
52	70		Основные шаги для подписания приложения, написанного с помощью Lazarus и/или Free Pascal:
53	71
54	72		1. Получите Developer ID (идентификатора разработчика) разработчика от Apple и установите его в цепочку ключей вашей системы.
55	73		2. Обратите внимание на буквенно-цифровой ключ вашего Developer ID (идентификатора разработчика) (он же TeamIdentifier).
56	74		3. Подпишите свое приложение командой codesign.
57	75		4. Подпишите свой установочный пакет с помощью команды productsign.
58	76
59	77		Невозможно использовать сертификаты от сторонних поставщиков, таких как Comodo, потому что они не пройдут Gatekeeper, для которого требуется сертификат, выданный разработчиком Apple. Также обратите внимание, что вы не можете подписывать приложения Windows с помощью сертификата разработчика Apple (на этот раз вам нужен сторонний сертификат Comodo и т.д.).
60	78
61	79		Приложение macOS, распространяемое за пределами Mac App Store, обычно имеет 3–4 отдельных уровня подписи:
62	80
63	81		- Само приложение будет иметь подписанный код с использованием сертификата приложения.
64	82		- Если у приложения есть установщик, файл пакета будет подписан сертификатом установщика.
65	83		- Образ диска, содержащий приложение или установщик, будет подписан сертификатом приложения.
66	84		- Образ диска будет [[Notarization for macOS 10.14.5+/ru\|нотариально заверен]], а затем удостоверение, сгенерированное нотариальной службой, будет к нему [[Notarization for macOS 10.14.5+/ru\|прикреплено]].
67	85
68	86		## Требования Gatekeeper'а
69	87
70	88		- Ваше приложение должно быть автономным, без неприемлемых внешних зависимостей. Единственными допустимыми внешними зависимостями являются системные библиотеки. Все остальные зависимости следует скопировать в папку пакета MyApp.app. Gatekeeper отклоняет любое приложение, имеющее несистемные внешние зависимости.
71	89
72	90		- Все бинарные файлы внутри MyApp.app должны быть подписаны кодом.
73	91
74	92		- Все бинарные файлы должны находиться в стандартных местах внутри папки пакета MyApp.app. См.таблицу ниже.
75	93
76	94		\| Местоположение \| Описание \|
77	95		\|----\|----\|
78	96		\| Contents \| Верхний каталог содержимого пакета \|
79	97		\| Contents/MacOS \| Основной исполняемый файл; вспомогательные приложения и инструменты \|
80	98		\| Contents/Frameworks \| Фреймворки, библиотеки *.dylibs \|
81	99		\| Contents/PlugIns \| Плагины, как загружаемые, так и расширения \|
82	100		\| Contents/XPCServices \| Сервисы XPC \|
83	101		\| Contents/Helpers \| Вспомогательные приложения и инструменты \|
84	102		\| Contents/Library/Automator \| Действия автоматора \|
85	103		\| Contents/Library/Spotlight \| Импортеры Spotlight (средство поиска) \|
86	104		\| Contents/Library/LoginItems \| Устанавливаемые элементы входа \|
87	105		\| Contents/Library/LaunchServices \| Привилегированные вспомогательные инструменты, устанавливаемые инфраструктурой ServiceManagement. \|
88	106
89	107		Стандартное местоположение для кода внутри бандла (пакета)
90	108
91	109		Примечание: Никакие недвоичные файлы никогда не должны находиться в папках, указанных в таблице выше.
92	110
93	111		## Использование механизма codesign для подписи вашего приложения
94	112
95	113		1. Подпишите свое приложение с помощью:
96	114
97	115		``` bash
98	116		codesign -f -o runtime --timestamp -s "Developer ID Application: YOUR NAME (TEAM_ID)" /path/to/bundle.app
99	117		```
100	118
101	119		2. Отображение основной информации о результате процесса подписания:
102	120
103	121		``` bash
104	122		codesign -dv -r- /path/to/bundle.app
105	123		```
106	124
107	125		Если ваше приложение было успешно подписано, эта команда вернет информацию, подобную приведенной ниже:
108	126
109	127		Executable=/Users/apple/Desktop/your.app/Contents/MacOS/yourappname
110	128		Identifier=org.yourdomain.yourappname
111	129		Format=app bundle with Mach-O thin (x86_64)
112	130		CodeDirectory v=20500 size=101470 flags=0x10000(runtime) hashes=3164+3 location=embedded
113	131		Signature size=9063
114	132		Timestamp=7 Dec 2019 at 18:36:08
115	133		Info.plist entries=16
116	134		TeamIdentifier=<10 alpha numeric digits>
117	135		Runtime Version=10.14.0
118	136		Sealed Resources version=2 rules=13 files=45
119	137		designated => identifier "org.yourdomain.yourappname" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists / and certificate leaf[field.1.2.840.113635.100.6.1.13] / exists */ and certificate leaf[subject.OU] = <10 alpha numeric digits>
120	138
121	139		3. Подтвердите свою подпись:
122	140
123	141		``` bash
124	142		codesign -vv /path/to/bundle.app
125	143		```
126	144
127	145		Если ваше приложение было успешно подписано, эта команда вернет строки "valid on disk"(действительно на диске) и "satisfies its Designated Requirement"(удовлетворяет назначенному требованию) соответственно после пути к вашему приложению.
128	146
129	147		## Использование механизма productsign для подписи установщика pkg
130	148
131	149		1. Подпишите файл pkg установщика с помощью:
132	150
133	151		``` bash
134	152		productsign --timestamp --sign "Developer ID Installer: YOUR NAME (TEAM_ID)" /path/to/unsigned.pkg /path/to/signed.pkg
135	153		```
136	154
137	155		2. Подтвердите свою подпись с помощью:
138	156
139	157		``` bash
140	158		spctl -vv --assess --type install /path/to/your.pkg
141	159		```
142	160
143	161		который должен давать информацию, подобную этой, если все закончилось успешно:
144	162
145	163		your.pkg: accepted
146	164		source=Developer ID
147	165		origin=Developer ID Installer: YOUR NAME (<10 alpha numeric digits>)
148	166
149	167		## Использование механизма codesign для подписи образа диска
150	168
151	169		Начиная с macOS 10.11.5, вы можете применять подпись кода к сжатым образам дисков только для чтения, которые вы используете для распространения содержимого. В этом случае вам не нужно отдельно подписывать ваше приложение.
152	170
153	171		1. Подпишите образ диска с помощью:
154	172
155	173		``` bash
156	174		codesign -f -o runtime --timestamp -s "Developer ID Application: YOUR NAME (TEAM_ID)" /path/to/YourImage.dmg
157	175		```
158	176
159	177		2. Подтвердите свою подпись с помощью:
160	178
161	179		``` bash
162	180		spctl -a -t open --context context:primary-signature -vv /path/to/YourImage.dmg
163	181		```
164	182
165	183		который должен выдать информацию, подобную этой, если все прошло успешно:
166	184
167	185		YourImage.dmg: accepted
168	186		source=Developer ID
169	187		origin=Developer ID Application: YOUR NAME (<10 alpha numeric digits>)
170	188
171	189		После 3 февраля 2020 года Apple полностью вводит нотариальное заверение для macOS 10.14.5+ (Mojave), в результате чего вышеуказанная проверка образа вашего диска теперь будет возвращать информацию, подобную этой:
172	190
173	191		YourImage.dmg: rejected
174	192		source=Unnotarized Developer ID
175	193		origin=Developer ID Application: YOUR NAME (<10 alpha numeric digits>)
176	194
177	195		Подробнее см. [[Notarization for macOS 10.14.5+/ru\|Нотаризация для macOS 10.14.5+]].
178	196
179	197		## Обновление подписанного файла
180	198
181	199		Всякий раз, когда вы обновляете подписанный файл, создавайте новый файл. Не копируйте новый подписанный файл поверх старого подписанного файла.
182	200
183	201		В частности, информация о подписи кода (хэш каталога кода) висит на vnode в ядре, и изменение файла за этим кешем вызовет проблемы. Вам нужен новый vnode, а значит новый файл, то есть новый inode. Задокументировано в сессии 703 WWDC 2019 «Все о нотариальном заверении» — см. [слайд 65 (PDF)](https://devstreaming-cdn.apple.com/videos/wwdc/2019/703yqvyjv9mi5ur6/703/703_all_about_notarization.pdf).
184	202
185	203		## Подписание ad hoc кода (в особых случаях)
186	204
187	205		Это особенно важно для процессоров Apple ARM64 M1, которые требуют, чтобы весь нативный код был подписан корректно (если только ad hoc), иначе операционная система не будет его выполнять, вместо этого убивая его при запуске. Чтобы подписать приложение ad hoc, выполните:
188	206
189	207		` codesign --force --deep -s - lazarus.app`
190	208
191	209		или, чтобы подписать исполняемый файл в особых случаях, выполните:
192	210
193	211		` codesign --force -s - lazarus`
194	212
195	213		Одиночный тире/дефис сам по себе для удостоверения делает его специальной подписью без сертификата.
196	214
197	215		Вы можете проверить действительность подписанного исполняемого файла ad hoc с помощью:
198	216
199	217		` codesign -dv -r- lazarus`
200	218
201	219		который должен вывести текст, аналогичный приведенному ниже:
202	220
203	221		`Executable=/Users/trev/lazarus-src/lazarus`\
204	222		`Identifier=lazarus`\
205	223		`Format=Mach-O thin (arm64)`\
206	224		`CodeDirectory v=20400 size=336137 flags=0x2(adhoc) hashes=10498+2 location=embedded`\
207	225		`Signature=adhoc`\
208	226		`Info.plist=not bound`\
209	227		`TeamIdentifier=not set`\
210	228		`Sealed Resources=none`\
211	229		`# designated => cdhash H"2e6f474452344d6fa42feee3db14a05c14d595a3"`
212	230
213	231		В тех случаях, когда вы скомпилировали исполняемый файл самостоятельно, компоновщик macOS специально подпишет исполняемый файл для вас, и в этом случае вам не нужно ничего делать. Вы можете проверить действительность с помощью приведенной выше команды, и в этом случае в строке вывода CodeDirectory будет указано, что компоновщик подписал исполняемый файл специальной подписью следующим образом:
214	232
215	233		` CodeDirectory v=20400 size=336032 flags=0x20002(adhoc,linker-signed) hashes=10498+0 location=embedded`
216	234
217	235		## Подписывание кода двоичного файла x86_64 на машине aarch64
218	236
219	237		Архитектура подписи кода macOS поддерживает два разных формата хэшей:
220	238
221	239		- sha1, исходный формат хэша, который сейчас считается устаревшим
222	240		- sha256, новый формат, поддержка которого была добавлена в macOS 10.11
223	241
224	242		`Codesign` должен выбрать формат подписи в зависимости от цели развертывания:
225	243
226	244		- Если целью развертывания является ОС 10.11 или более поздняя версия, вы получаете sha256.
227	245		- Если ваша цель развертывания ОС более ранняя, вы получите как sha1, так и sha256.
228	246
229	247		Проблема возникает из-за того, что при сборке для Intel и Apple Silicon цели развертывания разные. Вы можете установить цель развертывания на 10.9, но в Apple Silicon она повышена до минимальной системы Apple Silicon, 11.0. Итак, какую цель развертывания оно выбирает?
230	248
231	249		Вобщем, полный ответ на этот вопрос сложен, но краткое изложение заключается в том, что оно выбирает цель развертывания текущей архитектуры, то есть Intel, если вы собираете на Intel, и Apple Silicon, если вы собираете на Apple Silicon.
232	250
233	251		В результате у вас возникают проблемы, если ваша цель развертывания меньше 10.11 и вы подписываетесь на Apple Silicon. Когда вы запускаете, скажем, macOS 10.10, система ищет хэш sha1, не находит и жалуется.
234	252
235	253		Обходной путь заключается в предоставлении аргумента `--digest-algorithm=sha1,sha256` для `codesign`, который переопределяет логику выбора хэша в `codesign` и заставляет его включать оба хэша.
236	254
237	255		## Как установить сертификаты на второй компьютер
238	256
239	257		Есть два способа сделать это:
240	258
241	259		1. с помощью приложения Keychain Access (Связка ключей)
242	260		2. с помощью Xcode.
243	261
244	262		### Использование приложения Keychain Access (Связка ключей)
245	263
246	264		- На первом компьютере с сертификатами откройте приложение Keychain Access и создайте новую связку ключей. Теперь выберите существующую связку ключей для входа, а затем My Certificates (мои сертификаты). Ваши сертификаты должны отображаться справа. С левой стороны должна быть стрелка раскрытия, и ее выбор должен показать ваш закрытый ключ. Выберите каждый сертификат, скопируйте и вставьте (не перетаскивайте, иначе вы удалите его из цепочки для ключей входа) в новую цепочку для ключей.
247	265
248	266		- Скопируйте только что созданную цепочку для ключей с первого компьютера на второй компьютер, откройте ее с помощью приложения Keychain Access и скопируйте/вставьте/перетащите сертификат в цепочку для входа на второй компьютер.
249	267
250	268		### Использование Xcode
251	269
252	270		- На первом компьютере с сертификатами откройте Xcode и перейдите в Preferences \> Accounts (Настройки \> Учетные записи), выберите свою учетную запись, выберите значок шестеренки в левом нижнем углу, выберите Export Apple ID (Экспорт Apple ID) и Code Signing Assets (Активы для подписи кода), а затем сохраните файл.
253	271
254	272		- Скопируйте файл профиля разработчика, который вы сохранили на своем первом компьютере, на второй компьютер, откройте Xcode, перейдите в Preferences \> Accounts (Настройки \> Учетные записи), выберите свою учетную запись, выберите символ шестеренки в левом нижнем углу, а затем выберите Import Apple ID (Импортировать Apple ID) и Code Signing Assets (Активы для подписи кода).
255	273
256	274		## Как проверить, какие сертификаты установлены
257	275
258	276		После того, как вы создали или импортировали сертификаты на свой компьютер, вы можете проверить их наличие, открыв терминал Applications \> Utilities \> Terminal и выполнив следующую команду:
259	277
260	278		`$ security find-identity -p basic -v`
261	279
262	280		Эта команда выведет список всех доступных сертификатов на этом компьютере. Убедитесь, что вы видите наличие Developer ID Application и Developer ID Installer. Если вы являетесь участником нескольких команд, вы можете увидеть несколько сертификатов для каждой команды.
263	281
264	282		Вы можете идентифицировать сертификаты по шестнадцатеричному номеру или описательному имени, например, "Developer ID Application: Your Name (AB123456DE)".
265	283
266	284		Десятизначный буквенно-цифровой код в конце вашего имени — это Developer Team ID (идентификатор вашей команды разработчиков). Если вы являетесь членом нескольких команд разработчиков, у вас будет несколько сертификатов, и идентификатор команды поможет вам отличить их.
267	285
268	286		## См.также
269	287
270	288		- [[macOS Big Sur changes for developers\|Подписание кода: Intel в сравнеии Apple Silicon]]
271	289		- [[Apple Developer Certificates]]
272	290		- [[Notarization for macOS 10.14.5+]]
273	291		- [[Hardened runtime for macOS]]
274	292		- [[Sandboxing for macOS]]
275	293		- [[Signing and Notarization FAQ]]
276	294		- [[macOS Gatekeeper Debugging Tips]]
277	295
278	296		## Внешние ссылки
279	297
280	298		- [Apple Developer portal](https://developer.apple.com/)
281	299		- [Apple: Code Signing Overview](https://developer.apple.com/support/technical/code-signing/)
282	300		- [Apple: Code Signing Guide](https://developer.apple.com/library/mac/documentation/Security/Conceptual/CodeSigningGuide/)
283	301		- [Apple: TN2206 - macOS Code Signing In Depth](https://developer.apple.com/library/archive/technotes/tn2206/_index.html)
284	302		- [Apple: Code signing x86_64 binaries on aarch64](https://developer.apple.com/forums/thread/673323).
285	303
286	304		---
287	305		From the Free Pascal wiki, page "Code Signing for macOS/ru", as it stood on 2022-02-28 after a change by Alextp, out of the wiki's dump of 2024-05-26. Copyright stays with the author who wrote it, according to the old wiki's [[Licensing]] page. If you have concerns about this material, [message the admin](/wiki-contact).

Back to history