Code Signing for macOS/ru: what changed

Revision 1 to 2. 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		-	которая по-прежнему работает до macOS Catalina включительно. Лучшей, как и более безопасной, альтернативой было вместо этого обойти Gatekeeper, открыв приложение из контекстного меню по клику правой кнопки мыши, или по клику с зажатой <span class="kbd">Ctrl</span>. Это по-прежнему вызывало бы диалоговое окно предупреждения, но теперь оно бы содержало кнопку Открыть для успешного запуска приложения. Этот метод обхода Gatekeeper по-прежнему работает в macOS Catalina, за исключением того, что в Catalina вам нужно запустить приложение во второй раз, удерживая <span class="kbd">Ctrl</span> или щелкнув правой кнопкой мыши, чтобы успешно обойти Gatekeeper - при первом запуске приложения Gatekeeper не может быть обойден независимо от того, удерживаете ли вы <span class="kbd">Ctrl</span> или щелкаете правой кнопкой мыши или нет.
	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		-	Исполняемые файлы Intel, запущенные под Big Sur на процессоре Apple M1 через Rosetta 2, по-прежнему могут быть запущены, даже если они не подписаны, кликом ЛКМ с зажатой <span class="kbd">Ctrl</span> или кликом ПКМ мыши для обхода Gatekeeper.
	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	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
49	49
50	50		## Обзор
51	51
52	52		Основные шаги для подписания приложения, написанного с помощью Lazarus и/или Free Pascal:
53	53
54	54		1. Получите Developer ID (идентификатора разработчика) разработчика от Apple и установите его в цепочку ключей вашей системы.
55	55		2. Обратите внимание на буквенно-цифровой ключ вашего Developer ID (идентификатора разработчика) (он же TeamIdentifier).
56	56		3. Подпишите свое приложение командой codesign.
57	57		4. Подпишите свой установочный пакет с помощью команды productsign.
58	58
59	59		Невозможно использовать сертификаты от сторонних поставщиков, таких как Comodo, потому что они не пройдут Gatekeeper, для которого требуется сертификат, выданный разработчиком Apple. Также обратите внимание, что вы не можете подписывать приложения Windows с помощью сертификата разработчика Apple (на этот раз вам нужен сторонний сертификат Comodo и т.д.).
60	60
61	61		Приложение macOS, распространяемое за пределами Mac App Store, обычно имеет 3–4 отдельных уровня подписи:
62	62
63	63		- Само приложение будет иметь подписанный код с использованием сертификата приложения.
64	64		- Если у приложения есть установщик, файл пакета будет подписан сертификатом установщика.
65	65		- Образ диска, содержащий приложение или установщик, будет подписан сертификатом приложения.
66	66		- Образ диска будет [[Notarization for macOS 10.14.5+/ru\|нотариально заверен]], а затем удостоверение, сгенерированное нотариальной службой, будет к нему [[Notarization for macOS 10.14.5+/ru\|прикреплено]].
67	67
68	68		## Требования Gatekeeper'а
69	69
70	70		- Ваше приложение должно быть автономным, без неприемлемых внешних зависимостей. Единственными допустимыми внешними зависимостями являются системные библиотеки. Все остальные зависимости следует скопировать в папку пакета MyApp.app. Gatekeeper отклоняет любое приложение, имеющее несистемные внешние зависимости.
71	71
72	72		- Все бинарные файлы внутри MyApp.app должны быть подписаны кодом.
73	73
74	74		- Все бинарные файлы должны находиться в стандартных местах внутри папки пакета MyApp.app. См.таблицу ниже.
75	75
76	76		\| Местоположение \| Описание \|
77	77		\|----\|----\|
78	78		\| Contents \| Верхний каталог содержимого пакета \|
79	79		\| Contents/MacOS \| Основной исполняемый файл; вспомогательные приложения и инструменты \|
80	80		\| Contents/Frameworks \| Фреймворки, библиотеки *.dylibs \|
81	81		\| Contents/PlugIns \| Плагины, как загружаемые, так и расширения \|
82	82		\| Contents/XPCServices \| Сервисы XPC \|
83	83		\| Contents/Helpers \| Вспомогательные приложения и инструменты \|
84	84		\| Contents/Library/Automator \| Действия автоматора \|
85	85		\| Contents/Library/Spotlight \| Импортеры Spotlight (средство поиска) \|
86	86		\| Contents/Library/LoginItems \| Устанавливаемые элементы входа \|
87	87		\| Contents/Library/LaunchServices \| Привилегированные вспомогательные инструменты, устанавливаемые инфраструктурой ServiceManagement. \|
88	88
89	89		Стандартное местоположение для кода внутри бандла (пакета)
90	90
91	91		Примечание: Никакие недвоичные файлы никогда не должны находиться в папках, указанных в таблице выше.
92	92
93	93		## Использование механизма codesign для подписи вашего приложения
94	94
95	95		1. Подпишите свое приложение с помощью:
96	96
97	97		``` bash
98	98		codesign -f -o runtime --timestamp -s "Developer ID Application: YOUR NAME (TEAM_ID)" /path/to/bundle.app
99	99		```
100	100
101	101		2. Отображение основной информации о результате процесса подписания:
102	102
103	103		``` bash
104	104		codesign -dv -r- /path/to/bundle.app
105	105		```
106	106
107	107		Если ваше приложение было успешно подписано, эта команда вернет информацию, подобную приведенной ниже:
108	108
109	109		Executable=/Users/apple/Desktop/your.app/Contents/MacOS/yourappname
110	110		Identifier=org.yourdomain.yourappname
111	111		Format=app bundle with Mach-O thin (x86_64)
112	112		CodeDirectory v=20500 size=101470 flags=0x10000(runtime) hashes=3164+3 location=embedded
113	113		Signature size=9063
114	114		Timestamp=7 Dec 2019 at 18:36:08
115	115		Info.plist entries=16
116	116		TeamIdentifier=<10 alpha numeric digits>
117	117		Runtime Version=10.14.0
118	118		Sealed Resources version=2 rules=13 files=45
119	119		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	120
121	121		3. Подтвердите свою подпись:
122	122
123	123		``` bash
124	124		codesign -vv /path/to/bundle.app
125	125		```
126	126
127	127		Если ваше приложение было успешно подписано, эта команда вернет строки "valid on disk"(действительно на диске) и "satisfies its Designated Requirement"(удовлетворяет назначенному требованию) соответственно после пути к вашему приложению.
128	128
129	129		## Использование механизма productsign для подписи установщика pkg
130	130
131	131		1. Подпишите файл pkg установщика с помощью:
132	132
133	133		``` bash
134	134		productsign --timestamp --sign "Developer ID Installer: YOUR NAME (TEAM_ID)" /path/to/unsigned.pkg /path/to/signed.pkg
135	135		```
136	136
137	137		2. Подтвердите свою подпись с помощью:
138	138
139	139		``` bash
140	140		spctl -vv --assess --type install /path/to/your.pkg
141	141		```
142	142
143	143		который должен давать информацию, подобную этой, если все закончилось успешно:
144	144
145	145		your.pkg: accepted
146	146		source=Developer ID
147	147		origin=Developer ID Installer: YOUR NAME (<10 alpha numeric digits>)
148	148
149	149		## Использование механизма codesign для подписи образа диска
150	150
151	151		Начиная с macOS 10.11.5, вы можете применять подпись кода к сжатым образам дисков только для чтения, которые вы используете для распространения содержимого. В этом случае вам не нужно отдельно подписывать ваше приложение.
152	152
153	153		1. Подпишите образ диска с помощью:
154	154
155	155		``` bash
156	156		codesign -f -o runtime --timestamp -s "Developer ID Application: YOUR NAME (TEAM_ID)" /path/to/YourImage.dmg
157	157		```
158	158
159	159		2. Подтвердите свою подпись с помощью:
160	160
161	161		``` bash
162	162		spctl -a -t open --context context:primary-signature -vv /path/to/YourImage.dmg
163	163		```
164	164
165	165		который должен выдать информацию, подобную этой, если все прошло успешно:
166	166
167	167		YourImage.dmg: accepted
168	168		source=Developer ID
169	169		origin=Developer ID Application: YOUR NAME (<10 alpha numeric digits>)
170	170
171	171		После 3 февраля 2020 года Apple полностью вводит нотариальное заверение для macOS 10.14.5+ (Mojave), в результате чего вышеуказанная проверка образа вашего диска теперь будет возвращать информацию, подобную этой:
172	172
173	173		YourImage.dmg: rejected
174	174		source=Unnotarized Developer ID
175	175		origin=Developer ID Application: YOUR NAME (<10 alpha numeric digits>)
176	176
177	177		Подробнее см. [[Notarization for macOS 10.14.5+/ru\|Нотаризация для macOS 10.14.5+]].
178	178
179	179		## Обновление подписанного файла
180	180
181	181		Всякий раз, когда вы обновляете подписанный файл, создавайте новый файл. Не копируйте новый подписанный файл поверх старого подписанного файла.
182	182
183	183		В частности, информация о подписи кода (хэш каталога кода) висит на vnode в ядре, и изменение файла за этим кешем вызовет проблемы. Вам нужен новый vnode, а значит новый файл, то есть новый inode. Задокументировано в сессии 703 WWDC 2019 «Все о нотариальном заверении» — см. [слайд 65 (PDF)](https://devstreaming-cdn.apple.com/videos/wwdc/2019/703yqvyjv9mi5ur6/703/703_all_about_notarization.pdf).
184	184
185	185		## Подписание ad hoc кода (в особых случаях)
186	186
187	187		Это особенно важно для процессоров Apple ARM64 M1, которые требуют, чтобы весь нативный код был подписан корректно (если только ad hoc), иначе операционная система не будет его выполнять, вместо этого убивая его при запуске. Чтобы подписать приложение ad hoc, выполните:
188	188
189	189		` codesign --force --deep -s - lazarus.app`
190	190
191	191		или, чтобы подписать исполняемый файл в особых случаях, выполните:
192	192
193	193		` codesign --force -s - lazarus`
194	194
195	195		Одиночный тире/дефис сам по себе для удостоверения делает его специальной подписью без сертификата.
196	196
197	197		Вы можете проверить действительность подписанного исполняемого файла ad hoc с помощью:
198	198
199	199		` codesign -dv -r- lazarus`
200	200
201	201		который должен вывести текст, аналогичный приведенному ниже:
202	202
203	203		`Executable=/Users/trev/lazarus-src/lazarus`\
204	204		`Identifier=lazarus`\
205	205		`Format=Mach-O thin (arm64)`\
206	206		`CodeDirectory v=20400 size=336137 flags=0x2(adhoc) hashes=10498+2 location=embedded`\
207	207		`Signature=adhoc`\
208	208		`Info.plist=not bound`\
209	209		`TeamIdentifier=not set`\
210	210		`Sealed Resources=none`\
211	211		`# designated => cdhash H"2e6f474452344d6fa42feee3db14a05c14d595a3"`
212	212
213	213		В тех случаях, когда вы скомпилировали исполняемый файл самостоятельно, компоновщик macOS специально подпишет исполняемый файл для вас, и в этом случае вам не нужно ничего делать. Вы можете проверить действительность с помощью приведенной выше команды, и в этом случае в строке вывода CodeDirectory будет указано, что компоновщик подписал исполняемый файл специальной подписью следующим образом:
214	214
215	215		` CodeDirectory v=20400 size=336032 flags=0x20002(adhoc,linker-signed) hashes=10498+0 location=embedded`
216	216
217	217		## Подписывание кода двоичного файла x86_64 на машине aarch64
218	218
219	219		Архитектура подписи кода macOS поддерживает два разных формата хэшей:
220	220
221	221		- sha1, исходный формат хэша, который сейчас считается устаревшим
222	222		- sha256, новый формат, поддержка которого была добавлена в macOS 10.11
223	223
224	224		`Codesign` должен выбрать формат подписи в зависимости от цели развертывания:
225	225
226	226		- Если целью развертывания является ОС 10.11 или более поздняя версия, вы получаете sha256.
227	227		- Если ваша цель развертывания ОС более ранняя, вы получите как sha1, так и sha256.
228	228
229	229		Проблема возникает из-за того, что при сборке для Intel и Apple Silicon цели развертывания разные. Вы можете установить цель развертывания на 10.9, но в Apple Silicon она повышена до минимальной системы Apple Silicon, 11.0. Итак, какую цель развертывания оно выбирает?
230	230
231	231		Вобщем, полный ответ на этот вопрос сложен, но краткое изложение заключается в том, что оно выбирает цель развертывания текущей архитектуры, то есть Intel, если вы собираете на Intel, и Apple Silicon, если вы собираете на Apple Silicon.
232	232
233	233		В результате у вас возникают проблемы, если ваша цель развертывания меньше 10.11 и вы подписываетесь на Apple Silicon. Когда вы запускаете, скажем, macOS 10.10, система ищет хэш sha1, не находит и жалуется.
234	234
235	235		Обходной путь заключается в предоставлении аргумента `--digest-algorithm=sha1,sha256` для `codesign`, который переопределяет логику выбора хэша в `codesign` и заставляет его включать оба хэша.
236	236
237	237		## Как установить сертификаты на второй компьютер
238	238
239	239		Есть два способа сделать это:
240	240
241	241		1. с помощью приложения Keychain Access (Связка ключей)
242	242		2. с помощью Xcode.
243	243
244	244		### Использование приложения Keychain Access (Связка ключей)
245	245
246	246		- На первом компьютере с сертификатами откройте приложение Keychain Access и создайте новую связку ключей. Теперь выберите существующую связку ключей для входа, а затем My Certificates (мои сертификаты). Ваши сертификаты должны отображаться справа. С левой стороны должна быть стрелка раскрытия, и ее выбор должен показать ваш закрытый ключ. Выберите каждый сертификат, скопируйте и вставьте (не перетаскивайте, иначе вы удалите его из цепочки для ключей входа) в новую цепочку для ключей.
247	247
248	248		- Скопируйте только что созданную цепочку для ключей с первого компьютера на второй компьютер, откройте ее с помощью приложения Keychain Access и скопируйте/вставьте/перетащите сертификат в цепочку для входа на второй компьютер.
249	249
250	250		### Использование Xcode
251	251
252	252		- На первом компьютере с сертификатами откройте Xcode и перейдите в Preferences \> Accounts (Настройки \> Учетные записи), выберите свою учетную запись, выберите значок шестеренки в левом нижнем углу, выберите Export Apple ID (Экспорт Apple ID) и Code Signing Assets (Активы для подписи кода), а затем сохраните файл.
253	253
254	254		- Скопируйте файл профиля разработчика, который вы сохранили на своем первом компьютере, на второй компьютер, откройте Xcode, перейдите в Preferences \> Accounts (Настройки \> Учетные записи), выберите свою учетную запись, выберите символ шестеренки в левом нижнем углу, а затем выберите Import Apple ID (Импортировать Apple ID) и Code Signing Assets (Активы для подписи кода).
255	255
256	256		## Как проверить, какие сертификаты установлены
257	257
258	258		После того, как вы создали или импортировали сертификаты на свой компьютер, вы можете проверить их наличие, открыв терминал Applications \> Utilities \> Terminal и выполнив следующую команду:
259	259
260	260		`$ security find-identity -p basic -v`
261	261
262	262		Эта команда выведет список всех доступных сертификатов на этом компьютере. Убедитесь, что вы видите наличие Developer ID Application и Developer ID Installer. Если вы являетесь участником нескольких команд, вы можете увидеть несколько сертификатов для каждой команды.
263	263
264	264		Вы можете идентифицировать сертификаты по шестнадцатеричному номеру или описательному имени, например, "Developer ID Application: Your Name (AB123456DE)".
265	265
266	266		Десятизначный буквенно-цифровой код в конце вашего имени — это Developer Team ID (идентификатор вашей команды разработчиков). Если вы являетесь членом нескольких команд разработчиков, у вас будет несколько сертификатов, и идентификатор команды поможет вам отличить их.
267	267
268	268		## См.также
269	269
270	270		- [[macOS Big Sur changes for developers\|Подписание кода: Intel в сравнеии Apple Silicon]]
271	271		- [[Apple Developer Certificates]]
272	272		- [[Notarization for macOS 10.14.5+]]
273	273		- [[Hardened runtime for macOS]]
274	274		- [[Sandboxing for macOS]]
275	275		- [[Signing and Notarization FAQ]]
276	276		- [[macOS Gatekeeper Debugging Tips]]
277	277
278	278		## Внешние ссылки
279	279
280	280		- [Apple Developer portal](https://developer.apple.com/)
281	281		- [Apple: Code Signing Overview](https://developer.apple.com/support/technical/code-signing/)
282	282		- [Apple: Code Signing Guide](https://developer.apple.com/library/mac/documentation/Security/Conceptual/CodeSigningGuide/)
283	283		- [Apple: TN2206 - macOS Code Signing In Depth](https://developer.apple.com/library/archive/technotes/tn2206/_index.html)
284	284		- [Apple: Code signing x86_64 binaries on aarch64](https://developer.apple.com/forums/thread/673323).
285	285
286	286		---
287	287		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