Ма c заверение приложения успешно, но оценка spctl отклоняет приложение из-за Qt Frameworks - PullRequest
0 голосов
/ 29 января 2020

В настоящее время мы пытаемся проверить наше приложение, чтобы распространить его за пределами магазина приложений. Мы включаем библиотеки OpenSceneGraph, а также фреймворки Qt в комплект приложения.

Вот как мы это сделали:

  • Подписанный исполняемый файл в папке Contents / MacOS

  • Подписанные библиотеки и платформы Qt

  • Подписанная папка App.app

  • zip .app и отправлено для нотариального заверения

Подписание исполняемого файла, библиотек и каркасов выполняется вручную с помощью команды codeign, а для подписи всего .app мы делаем следующее:

codesign --force --verify --verbose=3 --options runtime --timestamp --entitlements App.entitlements -s "Developer ID Application: Our Dev Id" App.app

Когда мы отправляем заархивированный .app для нотариального заверения, мы обычно получаем быстрый ответ, информирующий нас о том, что нотариальное завершение прошло успешно, но если мы пытаемся запустить spctl --verbose --assess --type execute -v App.app, мы получаем следующую ошибку:

App.app: отклонено (незапечатанное содержимое присутствует в каталоге root встроенного фреймворка)

Также, проверяя файл json с выходом нотариального заверения, мы видим ту же ошибку, но она помечена как предупреждение и проверка его с th CodeSign Ошибка не возвращается.

После небольшого копания мы поняли, что проблема связана с фреймворками Qt: в качестве контрмеры мы попытались представить то же приложение без фреймворков Qt, и на этот раз, когда пакет был успешно заверен нотариусом spctl тоже принял его. Следовательно, мы удалили все символические ссылки в каталоге root, переместили файлы .prl в папку Resources / и создали псевдоним A / в подпапке Versions /, как предлагалось в нескольких сообщениях на форуме, но мы не смогли чтобы spctl принял наш пакет с фреймворками Qt. Теперь в root каждого фреймворка есть только папка Versions и больше ничего (мы проверили с помощью ls-lha, чтобы убедиться)

Чего нам не хватает в этом? Есть ли способ, по крайней мере, получить подсказку о том, где находится незапечатанный контент, который расстраивает инструмент проверки?

Заранее спасибо

1 Ответ

1 голос
/ 03 февраля 2020

В итоге получается, что macdeployqt был способом к go, потому что он автоматически упорядочивает фреймворки таким образом, чтобы можно было подписать пакет без ошибок.

Наша проблема с некоторыми фреймворками, не добавляемыми macdeployqt, исчезла, когда мы обновились с Qt 5.12.2 до Qt 5.14.1

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...