Я работаю над правильным распространением пакета программного обеспечения для 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
Но это только самый распространенный вариант.
Жестко закодированный путь является частью «защищенной среды выполнения», которая является требованием для прохождения нотариуса Apple, сканера вредоносных программ. Изменение назначенного RPATH с помощью otool
возможно, но делает недействительной подпись кода, блокируя выполнение на машинах с безопасностью по умолчанию без подписи кода, по крайней мере, ad hoc.
Видеть
https://wiki.lazarus.freepascal.org/Code_Signing_for_macOS
Запуск исполняемого файла непосредственно из терминала не запускается через службы запуска, как при запуске в Finder. Launchservices начинает с проверки подписи на билете и проверки билета, поэтому в голом исполняемом файле эта информация будет отсутствовать.
Ричард, большое спасибо за подробный ответ. Распространяясь в виде ZIP-файла, я не совсем уверен, куда мои конечные пользователи будут помещать исполняемые файлы и библиотеки. Когда мы начали распространять на последних машинах Mac, я помню, что мы могли использовать своего рода «макросы», такие как @executable_path, в определениях RPATH: вы знаете, будет ли это принято?
Для нотариуса имеет значение только то, является ли окончательная резолюция относительной или абсолютной. Внутренняя структура остается действительной для макросов.
Благодаря предложениям Ричарда Барбера я наконец понял, как правильно кодировать, нотариально заверять и развертывать наши пакеты на Mac с усиленной средой выполнения. Я оставляю шаги, которые я предпринял ниже, для дальнейшего использования.
Вот шаги, которые мне нужно было выполнить:
xcrun notarytool submit
Как только tar.gz загружен на тестовую машину, наши инструменты командной строки могут быть правильно использованы терминалом. Как предположил Ричард Барбер, их нельзя запустить из Finder, но даже JDK в формате tar.gz показывает такое же поведение, так что я доволен этим.
Для нотариально заверенного программного обеспечения macOS это означает, что исполняемый файл будет иметь жестко запрограммированный путь к библиотеке и не будет работать с относительным путем. Обычно это означает установку RPATH на жесткий путь /Applications/myapp.app/Contents/Frameworks/ и псевдоним ваших двоичных файлов из /Applications/myapp.app/Contents/MacOS.