Ответ 1

Извините за ответ на мой собственный вопрос, но я не вижу другого способа, поскольку редактирование исходного вопроса приведет к тексту спагетти.

Я, наконец, решил свою проблему. Сначала кредит: (i) Ответ на мой другой stackoverflow question был очень полезен и (ii) я получил очень хороший (оплаченный) совет от официального разработчика Apple, путем подачи так называемого инцидента технической поддержки (TSI).

На основе всего этого я теперь могу привести здесь очень краткий рецепт того, как получить приложение Mac успешно обработано GateKeeper. После подробного описания рецепта я покажу, какова была моя первоначальная ошибка.

Цель: после разработки приложения Mac вне Xcode, чтобы GateKeeper выдавал предупреждение "Загружено из Интернета..." тремя кнопками, один из которых "открыт".

Отказ: когда GateKeeper выдает предупреждение с текстом ".. unidentified developer.." или текст ".. неподтвержденный разработчик.." с - в обоих случаях - сообщение с одной кнопкой OK.

Получение вашего приложения готовым к использованию GateKeeper включает в себя три шага:

• Сделайте свое приложение автономным без каких-либо неприемлемых внешних зависимостей. Единственными приемлемыми внешними зависимостями являются системные библиотеки. Все другие зависимости должны быть скопированы в вашу папку MyApp.app. GateKeeper отклоняет любое приложение, которое имеет несистемные внешние зависимости.
• Запрещается размещать двоичные файлы на незаконных позициях внутри папки MyApp.app. Библиотеки входят в MyApp/Contents/Framework, и исполняемый файл переходит в MyApp/Contents/MacOS
• Все двоичные файлы внутри MyApp должны иметь цифровую подпись. Затем должна быть подписана папка MyApp.app. Для этого подписания необходим сертификат Apple Developer Application Application...

Наш рецепт автоматический. Все работы выполняются одним script. В случае Qt Creator мы используем qmake script, где мы получаем доступ к системной оболочке с помощью команды $$system. При использовании любой из системных команд (Xcode) codesign, spctl или check-signature предполагается, что вы перенаправили stderr на stdout, как указано в answer на вопрос. В противном случае вы не сможете поймать системный ответ при запуске этих утилит. Ниже мы не будем явно показывать это перенаправление.

ЗДЕСЬ НАШ РЕЦЕПТ

а. Создание автономного приложения:

• скопируйте (с помощью script) все необходимые двоичные файлы в папку MyApp.folder
• запустите (с script) install_name_tool -change и install_name_tool -id таким образом, чтобы все зависимости внутри приложения относились к типу @executable_path/../MacOS.. или @executable_path/../Frameworks
• запустите (с script) otool -L во всех двоичных файлах внутри папки MyApp.app и отметьте любую незаконную зависимость, такую ​​как "@rpath..." или абсолютные пути к файлу, не являющиеся системными путями. Обратите внимание, что otool -L не гарантируется найти все зависимости. Плагины часто выходят за горизонт otool. Вот почему вам нужна следующая проверка.
• запустите терминал в папке "MyApp.app/Contents/MacOS". Запустите export DYLD_PRINT_LIBRARIES=1. Затем запустите внутри одного окна терминала ./MyApp. Ваш терминал будет заполнен более ста загруженными библиотеками. Повторите этот список для запрещенных библиотек (библиотеки присутствуют на вашем компьютере, но не на компьютере ваших клиентов).
• доказательство пудинга в еде. Мы используем виртуальные машины MacInCloud и проверяем, работает ли там наше приложение. Альтернативным решением может быть Mac родственника, который не является разработчиком. Или вы также можете создать нового пользователя ( "тест" ) на своем Mac и скопировать приложение в папку "Загрузить" (или "Рабочий стол" или...). В последнем случае вы должны временно переименовать корневую папку вашей среды IDE, так как иначе пользовательский "тест" найдет там отсутствующие двоичные файлы.

B Подписывание приложения

6. Подписание: с помощью нашего script мы запускаем codesign --force --verify --verbose --sign \"Developer ID Application: ....\" \"/path/to/binary\" во всех двоичных файлах приложения, а затем в самой папке приложения. В каждом случае происходит отладка системы. Он должен содержать в каждом случае строку "подписанный Mach-O thin".
7. Проверка: Запустите (с помощью команды script) codesign --verify --verbose \"/path/to/binary\" в каждом бинарном приложении и в самом приложении и поймите системный ответ. Он должен в каждом случае содержать строки, "действующие на диске" и "удовлетворяет его назначенным требованиям".
8. Проверка GateKeeper: запустите (с script) spctl -a -t exec -vv /path/to/binary\" в каждом двоичном файле и в самой папке приложения. Системный отклик пойман. Он должен содержать во всех случаях строку "принятый источник".
9. check-signature: Запустите (с script) check-signature \"/path/to/banary\" в каждом двоичном файле и в самой папке приложения. Системный отклик пойман. Он должен содержать строку "ДА" в каждом случае.

C Внешняя проверка

10. Запишите свое приложение в один ZIP файл. Загрузка на один из ваших облачных серверов

11. GateKeepers хранит длинный список (обычно сотни элементов) исключений из своей общей роли gate-keeper. Ваше приложение не должно быть в этом списке, если вы хотите проверить GateKeeper. Вместо редактирования этого списка гораздо более простой трюк - это создание нового пользователя на вашем Mac. Войдите в систему этого пользователя и загрузите zip файл с интернет-сервера облаков. Finder автоматически распакует его. Нажмите здесь. Если GateKeeper сообщает вам, что он может открыть приложение, но он одновременно предупреждает вас, что он загружен из Интернета, пришло время захватить (белое) пиво.

Здесь требуется предупреждение GateKeeper:

Моя ошибка

Я сделал большую часть установки и подписания без явной проверки результата для каждого двоичного файла. После этого я использовал бы otool -L для нескольких двоичных файлов, но не для всех. Я пропустил тот факт, что при обновлении до Qt 5.5 из более ранней версии Qt двоичный libqminimal.dylib приобрел дополнительную зависимость, а именно: QtDBus. Я этого не заметил, но GateKeeper сделал.

Разработчики Qt могут задаться вопросом, почему мы не просто используем macdeployqt для развертывания приложения Qt на Mac. В первую очередь нам не нравится не использовать плохо документированные утилиты "черного ящика". На интернет-форумах существует довольно много людей, которые сообщают о проблемах с macdeployqt. Кроме того, при сравнении разных версий Qt библиотеки Qt могут иметь разные места установки (как сообщается otool-L). Когда у нас будет новая версия Qt, наш script сразу начнет кричать о запрещенных зависимостях. Таким образом мы получаем информацию о том, что изменилось в этой новой версии.

Ответ 2

adlag вопрос и самостоятельный ответ были неоценимы, помогая мне преодолеть одну и ту же проблему. Однако, как и его рецепт, некоторые утверждения не совсем правильные, поэтому я хотел бы предложить несколько дополнительных пунктов.

• Не нужно заменять записи @rpath в ваших двоичных файлах и динамических библиотеках с помощью операторов @executable_path. Операторы @rpath хороши, пока фактические записи rpath, встроенные в двоичные файлы, не являются абсолютными. Вы можете найти множество действительных наборов приложений Qt, которые используют rpath. Вы можете заставить его работать над тем, что сказал adlag, но вы можете делать работу самостоятельно.
• См. комментарий jil выше о том, как использовать otool -l $file | grep -A2 LC_RPATH и install_name_tool -delete_rpath $path $file для проверки и удаления внедренных путей в ваших двоичных файлах и библиотеках.
• См. https://developer.apple.com/library/content/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG207 для четкого объяснения того, почему GateKeeper жалуется на пути в ваших двоичных файлах и как вы можете увидеть конкретную жалобу в системный журнал.
• Если у вас есть проблема с абсолютными путями, сначала попробуйте исправить вашу сборку, а не использовать install_name_tool после факта.
• Если вы используете cmake, это, вероятно, полезно: https://cmake.org/Wiki/CMake_RPATH_handling#Mac_OS_X_and_the_RPATH
• Не запускайте spctl -a -t exec -vv /path/to/binary в файлах dylib. Вы получите ошибки о конверте ресурсов. Ожидается, что это не проблема.
• По моему опыту, macdeployqt работает нормально. Я решил проблему, изменив мою сборку, так что абсолютные пути не попали в файл dylib для нарушителя (libquazip). Я все еще использовал install_name_tool, чтобы удалить абсолютные пути к установке Qt. Затем я использовал macdeployqt для создания пакета, подписи пакета и создания файла DMG.

Ответ 3

Выяснил проблему после множества попыток.

В моем случае: Поврежденное приложение Pop Message появилось из-за отсутствия библиотек. Я создал файл .app с помощью QT. Для генерации dmg я использовался инструмент команды deploymacqt. Инструмент deploymacqt создает динамические библиотеки внутри .app, поэтому в основном, если мы координируем перед созданием dmg, этот alter будет манипулировать знаком кода. Итак, правильное исправление.

# Create dmg using 
    deploymacqt <yourapp.app> -dmg

# Open resulted dmg file, copy <yourapp.app> to different folder(let say /Documents/<yourapp.app>)

# Codesign the /Documents/<yourapp.app> using 
    codesign --deep --force --verify --verbose --sign "Developer ID Application: <developerid>" <yourapp.app>

# Verify using
    codesign --verify --verbose=4 <yourapp.app>
 * you should see something like this
    <yourapp.app>: valid on disk
    <yourapp.app>: satisfies its Designated Requirement

# Now create again the dmg file using dropdmg(https://c-command.com/dropdmg/) application, download, install dropdmg. set the cofiguration preferences with your developer id certificate in signing option.

# drag and drop <yourapp.app> to dropdmg app, wait for creation of dmg to complete. voila you have now successfully created dmg with proper developer id certification.

# verify resulted dmg again using   
     codesign --verify --verbose=4 <yourapp.dmg>
# you can also verify with gatekeeper
     spctl -a -t exec -vv <yourapp.dmg>

После того, как вы закончите с этим, вы не увидите сообщение pop, говорящее, что приложение повреждено или сломано или неизвестно разработчику.

Ответ 4

Мои два бита:

• Чтобы действительно проверить кодовое кодирование, мне пришлось либо загрузить мой DMG на сервера и загрузите его с помощью браузера или установите атрибут карантина вручную:

  APP_PATH="Any.app"
  xattr -w com.apple.quarantine '0081;5a37dc6a;Google Chrome;F15F7E1C-F894-4B7D-91B4-E110D11C4858' "$APP_PATH"
  xattr -l "$APP_PATH" # You should see the quarantine attribute here
  open "$APP_PATH"
  

  Если ваше приложение правильно подписано, вы увидите системный диалог с кнопка "Открыть".

  Я нашел значение атрибута карантина, посмотрев на другое .app скачан из Интернета. Я не знаю, что значение означает.

  Я действительно не понимаю, почему команда spctl говорит "принято" даже если служба Gatekeeper отказывает в открытии приложения.

• У меня появилось окно сообщения "Неизвестный разработчик", потому что мои рамки Qt были указаны как " @rpath/QtCore.framework". Меняя его на " @application_path/../Frameworks/QtCore.framework" с помощью install_name_tool, исправлена ​​проблема в моем приложении.