Проблемы с написанием кода и нотариальным заверением для Mac M1

Я работаю над правильным распространением пакета программного обеспечения для Mac ARMS (M1, M2...), который состоит из zip-файла, содержащего набор утилит командной строки и динамических библиотек, созданных с использованием инструментов командной строки (cc, c++ и т. д.).

До сих пор мне удавалось подписывать все мои исполняемые файлы и динамические библиотеки с помощью кода, используя сертификат ID разработчика моей компании, и успешно нотариально заверять почтовый индекс.

К сожалению, когда я загружаю zip с помощью браузера, мои инструменты командной строки показывают странное поведение: если я дважды щелкну по ним из Finder, я получу сообщение об ошибке, в котором говорится, что личность разработчика не может быть подтверждена, но если я запускаю из терминал большинство утилит работает. Я заметил, что если я загружаю последний jdk как .tar.gz, поведение с исполняемым файлом java будет таким же, поэтому мне интересно, является ли это ожидаемым поведением для утилит командной строки.

Тем не менее одна из утилит не работает, потому что она должна загружать динамические библиотеки. Я получаю сообщение об ошибке, говорящее о том, что относительные пути не разрешены в защищенных программах.

Мои вопросы: Ожидается ли поведение, описанное выше для исполняемых файлов командной строки? Есть ли способ разрешить моей программе, которая загружает динамическую библиотеку, работать, загружая динамические библиотеки, как это было раньше с нашими неподписанными пакетами для Intel Mac? Кто-нибудь знает, можно ли нотариально заверить и распространять такой пакет в формате .tar.gz, а не в zip?

Спасибо!

Для нотариально заверенного программного обеспечения macOS это означает, что исполняемый файл будет иметь жестко запрограммированный путь к библиотеке и не будет работать с относительным путем. Обычно это означает установку RPATH на жесткий путь /Applications/myapp.app/Contents/Frameworks/ и псевдоним ваших двоичных файлов из /Applications/myapp.app/Contents/MacOS.

Richard Barber 15.01.2023 05:04
Как установить PHP на Mac
Как установить PHP на Mac
PHP - это популярный язык программирования, который используется для разработки веб-приложений. Если вы используете Mac и хотите разрабатывать...
0
1
59
2
Перейти к ответу Данный вопрос помечен как решенный

Ответы 2

Для нотариально заверенного программного обеспечения macOS это означает, что исполняемый файл будет иметь жестко запрограммированный путь к библиотеке и не будет работать с относительным путем. Обычно это означает установку RPATH на жесткий путь

/Applications/myapp.app/Contents/Frameworks/

и псевдоним ваших двоичных файлов из

/Applications/myapp.app/Contents/MacOS

Но это только самый распространенный вариант.
Жестко закодированный путь является частью «защищенной среды выполнения», которая является требованием для прохождения нотариуса Apple, сканера вредоносных программ. Изменение назначенного RPATH с помощью otool возможно, но делает недействительной подпись кода, блокируя выполнение на машинах с безопасностью по умолчанию без подписи кода, по крайней мере, ad hoc.

Видеть

https://wiki.lazarus.freepascal.org/Code_Signing_for_macOS

Запуск исполняемого файла непосредственно из терминала не запускается через службы запуска, как при запуске в Finder. Launchservices начинает с проверки подписи на билете и проверки билета, поэтому в голом исполняемом файле эта информация будет отсутствовать.

Ричард, большое спасибо за подробный ответ. Распространяясь в виде ZIP-файла, я не совсем уверен, куда мои конечные пользователи будут помещать исполняемые файлы и библиотеки. Когда мы начали распространять на последних машинах Mac, я помню, что мы могли использовать своего рода «макросы», такие как @executable_path, в определениях RPATH: вы знаете, будет ли это принято?

ss900ie 16.01.2023 08:39

Для нотариуса имеет значение только то, является ли окончательная резолюция относительной или абсолютной. Внутренняя структура остается действительной для макросов.

Richard Barber 16.01.2023 21:00
Ответ принят как подходящий

Благодаря предложениям Ричарда Барбера я наконец понял, как правильно кодировать, нотариально заверять и развертывать наши пакеты на Mac с усиленной средой выполнения. Я оставляю шаги, которые я предпринял ниже, для дальнейшего использования.

Вот шаги, которые мне нужно было выполнить:

  • Убедитесь, что все динамические исполняемые файлы и библиотеки ссылаются на свои зависимости без использования относительных путей. Относительные пути могут быть заменены макросами, такими как @rpath, с помощью install_name_tool.
  • Подпись кода ко всем исполняемым файлам и всем динамическим библиотекам, предъявляющим иск к инструменту codesign, с действительным сертификатом дистрибутива Apple и ключом разработчика/организации.
  • После подписания поместите все в ZIP и отправьте на нотариальное заверение с помощью команды xcrun notarytool submit
  • Если нотариальное заверение прошло успешно, содержимое ZIP можно извлечь и поместить в .tar.gz без потери действительности.

Как только tar.gz загружен на тестовую машину, наши инструменты командной строки могут быть правильно использованы терминалом. Как предположил Ричард Барбер, их нельзя запустить из Finder, но даже JDK в формате tar.gz показывает такое же поведение, так что я доволен этим.

Другие вопросы по теме