Подпись кода + нотариальное заверение с помощью утилиты jpackage не работает в macOS
В некотором контексте я использую утилиту jpackage, чтобы попытаться создать подписанный файл DMG для доставки моим пользователям. Причина, по которой мне нужно подписать этот DMG, заключается в том, что я хотел бы нотариально заверить программное обеспечение. Кстати, я не уверен, возможно ли нотариальное заверение (пока) с помощью jpackage, но все равно пытаюсь.
Однако у меня возникают проблемы с использованием встроенных параметров подписи кода jpackage, что является предпосылкой для успешного нотариального заверения.
Я запускаю jpackage, используя параметры --mac-sign --mac-package-signing-prefix CardrDebate --mac-signing-key-user-name "Developer ID Application: ********** (*******)" (Я отредактировал фактический идентификатор разработчика, поскольку он опубликован в Stackru).
После создания образа приложения jpackage я проверил, действительно ли сгенерированный код подписан, перейдя к нескольким из сгенерированных файлов.dylib и попробовав codesign -vvv {filename}.dylib, а в codeign указано, что объект вообще не подписан (НЕ что он был подписан неправильно, а просто не подписан вообще).
Таким образом, я считаю, что моя проблема связана с моим (потенциально) неправильным использованием параметров подписи jpackage в macOS. Как мне их использовать?
5 ответов
Я продолжу и отвечу на свой вопрос, потому что в конечном итоге я выяснил, как подписать свое приложение и успешно нотариально заверить его в нотариальной службе Apple (мой продукт - http://cardr.x10.bz/).
Используйте параметр app-image jpackage для создания неподписанного пакета приложения.
Используйте автоматический сценарий bash для кодирования всех файлов dylib и исполняемых файлов внутри пакета приложения, используя
codesign -vvv --options runtime --deep --force --sign "Developer ID Application: ********" <filename>.Это многоэтапная процедура, поэтому я просто разделю ее на A / B / C.
3A) Найдите все файлы jar в MyApp.app/Contents/mods/, которые содержат встроенные файлы.dylib, и извлеките эти файлы в определенную папку (или напишите небольшую программу, которая сделает это за вас). Для меня мое приложение основывалось на JavaFX, поэтому многие библиотеки JavaFX содержали файлы.dylib в файлах jar. Однако, если вы просто используете библиотеки Java по умолчанию, вы можете пропустить шаг 4, поскольку библиотеки Java по умолчанию не содержат файлов.dylib. Причина, по которой нам нужно сделать этот шаг, заключается в том, что служба нотариального заверения Apple также проверяет эти встроенные файлы.dylib на наличие кодовой подписи.
3B) Используйте автоматический сценарий bash для кодирования всех файлов dylib, которые вы только что извлекли, используя codesign -vvv --options runtime --deep --force --sign "Developer ID Application: ********" <filename>.
3C) Добавьте каждый из подписанных файлов.dylib обратно в соответствующие файлы jar, чтобы заменить исходные встроенные файлы.dylib без подписи. Вот команда, которая может пригодиться:jar uf <path to jar file> <path to dylib file>. Обратите внимание, что второй указанный путь, путь к файлу dylib, также должен быть относительным расположением dylib в архиве. Подробнее читайте здесь - https://docs.oracle.com/javase/tutorial/deployment/jar/update.html.
Теперь, когда вы подписали каждый из исполняемых файлов и файлов dylib в.app, пора подписать сам.app. Пробег
codesign -vvv --force --sign "Developer ID Application: ********" MyApp.app.Теперь, когда вы подписали.app, вам нужно запустить jpackage в пакете приложений, чтобы создать из него DMG или PKG. Не стесняйтесь использовать функции подписи jpackage Mac, которые будут подписывать внешний DMG/PKG. Обратите внимание, что свойство
--mac-signing-key-user-name "My Developer Account Name (*******)"НЕ должен включать в сертификат часть сертификата "ID разработчика / приложение / установщик".Наконец, вы создали подписанный PKG/DMG, готовый к нотариальному заверению. Использовать
xcrun altool --notarize-app --username <apple-id> --password <app-specific-password> <MyApp.dmg or MyApp.pkg>. Дождитесь завершения нотариального заверения и убедитесь, что оно одобрено.Если нотариальное заверение прошло успешно (должно), вы можете прикрепить билет своего приложения к установщику PKG, используя
xcrun stapler staple MyApp.pkg.
Надеюсь это поможет!
К вашему сведению - погрузился в эту проблему в JDK 14.0.1 и хотел поделиться знаниями в качестве еще одного временного решения, пока jpackage не будет работать правильно.
В исходном пути JDK 14: src/jdk.incubator.jpackage/macosx/classes/jdk/incubator/jpackage/internal
файл MacAppBundler.java содержит эти строки (81 и 82): "Приложение с идентификатором разработчика: " + SIGNING_KEY_USER.fetchFrom(params),
где SIGNING_KEY_USER берет значение параметра --mac-signed-key-user-name из командной строки.
В этих строках использование jpackage для подписи DMG всегда не удавалось. ("Приложение с идентификатором разработчика:" не соответствует имени моего сертификата.)
ИЗМЕНИЛ эти строки, чтобы удалить "Приложение ID разработчика:" и следующий знак "+". При вызове jpackage в качестве значения параметра использовалось полное имя сертификата:
--mac-signed-key-user-name "Приложение стороннего разработчика Mac: Джон Смит (ABCDEFGHIJ)"
и jpackage теперь (очевидно) создаст и подпишет DMG. Разве не на самом деле пытались представить это в Apple Store, так что это еще может быть неполным.
Интересно, что исходный код MacAppStoreBundler.java действительно содержит правильные строки префикса "Стороннее приложение разработчика Mac:" и "Сторонний установщик разработчика Mac:", поэтому возникает подозрение, что jpackager на самом деле вызывает неправильные методы - но еще не разобрались с этим. Возможно, jpackage должен иметь некоторые дополнительные параметры, чтобы точно указать, что должно быть сделано (но вы можете подумать, что '--type dmg' вызовет правильную логику).
Основные (корявые) шаги по воспроизведению:
- Загрузите исходный код с https://hg.openjdk.java.net/jdk (выбран jdk14, зафиксируйте 6c954123ee8d).
- Загрузите и распакуйте.zip (или.gz или.bz2) в рабочий каталог
- Воспользуйтесь любым текстовым редактором, чтобы перейти по пути от src и изменить MacAppBundler.java, как указано выше.
- Откройте окно терминала и перейдите в каталог src.
- запустите make all, чтобы скомпилировать весь JDK 14
- запустите src/build/macosx-x86_64-server-release/images/jdk/bin/jpackage ...parameters...
Рабочий сквозной скрипт для моего приложения ( Slimbox) см.darwinраздел package.sh.
Еще одно обновление: с JavaFX/JDK 17.0.2 я смог создать файл .dmg следующим образом. Затем этот файл можно загрузить на веб-сервер и загрузить с помощью веб-браузера:
# no entitlements required.
# no further .dylib or .jar signing required.
jpackage --type dmg --mac-sign --mac-signing-key-user-name "YOUR_DEVELOPER_APPLICATION_ID" [...]
# .dmg signing is required for notarization.
codesign --timestamp -s "YOUR_DEVELOPER_APPLICATION_ID" "DMG_NAME"
# recommended notarization steps with verification
xcrun notarytool submit "DMG_NAME" --wait --keychain-profile "YOUR_PROFILE"
xcrun stapler staple "DMG_NAME"
spctl -a -t open --context context:primary-signature -vv "DMG_NAME"
Я просто хочу узнать больше о процессе. У меня есть приложение JavaFX 11, использующее Java 16 в процессе сборки. Описанный подход Soham работает. Однако вот некоторые моменты, которые я нашел:
- С Java 16 вам больше не нужен параметр «--deep» для подписи образа приложения (он также не рекомендуется для развертывания).
- Мне нужен был файл прав для подписи, то есть опция --entitlement для подписи. В противном случае приложение не запускается после подписания.
- Установщик может быть подписан с помощью параметров знака jpackage.
- Загрузка установщика в виде zip-архива для нотариального заверения работает должным образом.