Temurin-build: Поддержка усиленной среды выполнения MacOS

когда я пытаюсь добавить этот флаг, я получаю следующую ошибку:
error: invalid or inappropriate API flag(s) specified

@tkie У вас есть какие-нибудь дополнительные идеи?

Глядя на https://help.apple.com/xcode/mac/current/#/dev033e997ca , можно предположить, что нам может потребоваться кодирование на macOS 10.13 или выше, позвольте мне поиграть здесь.

Я использую XCode версии 10.3 (10G8) на MacOS 10.14.6.
Я не знаю, какая минимальная версия XCode поддерживает усиленную среду выполнения, но это довольно новая функция.

хорошо, так что я немного продвинулся здесь, я могу подписать, чтобы включить сборку jdk12. Чтобы обойти ошибку:

Error occurred during initialization of VM
Could not reserve enough space in CodeHeap 'non-nmethods' (2496K)

вам нужно добавить права в виде plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.security.cs.allow-jit</key>
    <true/>
    <key>com.apple.security.cs.allow-unsigned-executable-memory</key>
    <true/>
    <key>com.apple.security.cs.disable-executable-page-protection</key>
    <true/>
    <key>com.apple.security.cs.allow-dyld-environment-variables</key>
    <true/>
</dict>
</plist>

а затем добавьте --entitlements <path to entitlements.plist> в качестве флага при написании кода.

проверяя исполняемый файл, я теперь вижу параметр времени выполнения:

➜  Home codesign -dvvv ./bin/java
Executable=/Users/gdams/tmp/jdk-11.0.4+11/Contents/Home/bin/java
Identifier=net.java.openjdk.cmd
Format=Mach-O thin (x86_64)
CodeDirectory v=20500 size=832 flags=0x10000(runtime) hashes=17+5 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha1=89dde46e6d5094c92508bc3d95ecf04cbf2e5c6b
CandidateCDHash sha256=7504cd1dc13d553e9cb3d469a508900a34d3cbc7
Hash choices=sha1,sha256
CDHash=7504cd1dc13d553e9cb3d469a508900a34d3cbc7
Signature size=9037
Authority=Developer ID Application: London Jamocha Community CIC (VDX7B37674)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=30 Jul 2019 at 11:12:25
Info.plist entries=4
TeamIdentifier=VDX7B37674
Runtime Version=10.10.0
Sealed Resources=none
Internal requirements count=1 size=180

@tkie , можете ли вы подтвердить, что вышеизложенное также работает для вас? Если это произойдет, я внесу это изменение в сценарии сборки.

Мне также удалось заставить это работать на jdk8, добавив это в файл entitlements.plist:

<key>com.apple.security.cs.disable-library-validation</key>
<true/>

тестовое нотариальное заверение приложения jdk11: отчет (успешно)

тестовое нотариальное заверение приложения jdk12: отчет (успешно)

@gdams Извините, я никогда не собирал JDK сам. Я всегда скачивал бинарные дистрибутивы. Может быть, вы могли бы сделать свою сегодняшнюю тестовую сборку JDK 11 для MacOS доступной для скачивания где-нибудь? Затем я мог бы попытаться получить нотариальное заверение от Apple для своего приложения, в которое я хотел бы включить JDK. Так что я могу подтвердить, работает ли ваше изменение.

@tkie Я получил исправление, которое исправляет что-либо в JDK11+. Обратите внимание, что это изменение не будет заметно до нашего следующего выпуска (я обсужу с ребятами из Adopt возможность повторного выпуска, чтобы люди могли сразу его использовать.

В JDK8 у нас все еще есть проблема:

The binary uses an SDK older than the 10.9 SDK

Мое предложение заключалось бы в том, чтобы мы исследовали отправку сборки JDK8, оптимизированной для объединения (т. е. построенной на более поздней цепочке инструментов), но это может быть непростой задачей, поскольку для этого требуется загрузка бэкпортов из более поздних версий JDK в репозиторий JDK8u.

@tkie У меня есть сборка JDK12, которую вы можете попробовать здесь: https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk12u/job/jdk12u-mac-x64-hotspot/

Сборка JDK11:
https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk11u/job/jdk11u-mac-x64-hotspot/

@gdams Спасибо за сборку JDK12. Я могу подтвердить, что мое приложение, включая JRE из OpenJDK12U-jre_x64_mac_hotspot_2019-07-31-11-04.tar.gz, было нотариально заверено Apple.

@gdams Я также тестировал OpenJDK11U-jre_x64_mac_hotspot_2019-07-31-11-27.tar.gz. Нотариальное заверение с ним также прошло успешно.
С моей точки зрения проблема решена и нет необходимости исследовать Java 8.
Благодарим вас за решение этой проблемы для Java 11 и выше.

Мы также получаем ошибку «Двоичный файл использует SDK старше, чем SDK 10.9», когда пытаемся нотариально заверить наше приложение с включенной средой выполнения Java 1.8.

В настоящее время нам нужно оставаться с Java 1.8, поэтому мы не можем перейти на более новую версию Java.

Есть ли дата, когда будет доступна обновленная среда выполнения Java 1.8, которая пройдет этот нотариальный тест?

Я также могу подтвердить, что это исправлено с помощью https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk12u/job/jdk12u-mac-x64-hotspot/.

Когда можно ожидать сборку openjdk 8, прошедшую нотариальное заверение?

Когда можно ожидать сборку OpenJDK 8, прошедшую нотариальное заверение?

Возможно, в настоящее время ни один поставщик OpenJDK не поддерживает эту поддержку. Проблема в том, что jdk8u должен быть построен на Mac Os X 10.10, тогда как нотариальное заверение — это концепция 10.14.

Привет народ,
Я не уверен, что это полностью закрыто. Мы связываем последнюю версию macOS OpenJDK 11 JRE (OpenJDK11U-jre_x64_mac_hotspot_11.0.5_10.tar.gz) с нашим приложением, и хотя процесс нотариального заверения проходит успешно, мы получаем ряд предупреждений в журнале JSON, которые указывают на то, что (вероятно) произойдет сбой. в будущем. Например:

{
  "severity": "warning",
  "code": null,
  "path": "XYZ.app.zip/XYZ.app/Contents/jdk-11/bin/java",
  "message": "The executable does not have the hardened runtime enabled.",
  "docUrl": null,
  "architecture": "x86_64"
},

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

Я могу передать нашу копию журнала, если это будет полезно.

Вы добавили право на JIT-возможности? Без него нотариальное заверение не состоится. почти уверен, что JRE нуждается в этом.

https://developer.apple.com/documentation/security/hardened_runtime_entitlements

Я попробовал это, используя восходящий пример от @gdams. Вместо этого мы используем не Xcode, а инструменты командной строки. Возможно, мне нужно будет переключиться, но, надеюсь, я смогу этого избежать. Это может быть просто вопрос обновления шагов подписания; до нотариального заверения было проще...

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

Если кто-нибудь скажет мне, где найти журнал JSON, упомянутый @davideby при использовании XCode, я сделаю еще одно нотариальное заверение нашего программного обеспечения с помощью XCode и проверю, получаю ли я такие предупреждения.
Могу только сказать, что нотариальное заверение прошло успешно, но я еще не проверял лог-файл на наличие предупреждений.

Я работаю с этим документом . См., в частности, раздел «Проверка статуса вашего запроса».

@gdams Кажется, поддержка времени выполнения hardenend снова исчезла? Если я использую jdk-11.0.4+11.4, то нотариальное заверение работает. Но с jdk-11.0.5+10 я получаю сообщение об ошибке, что усиленная поддержка среды выполнения не включена.

Похоже, вы подписываете исполняемые файлы без усиленной опции времени выполнения. Попробуй
добавьте --option runtime в команду codesign.

Во вторник, 5 ноября 2019 г., 07:56 Дэвид Эби, [email protected] написал:

Привет народ,
Я не уверен, что это полностью закрыто. Мы собираем последнюю версию macOS
OpenJDK 11 JRE (OpenJDK11U-jre_x64_mac_hotspot_11.0.5_10.tar.gz) с нашим
приложение, и пока процесс нотариального заверения проходит успешно, мы получаем ряд
предупреждения в журнале JSON, которые указывают, что (вероятно) произойдет сбой в
будущее. Например:

{
"серьезность": "предупреждение",
"код": ноль,
"путь": "XYZ.app.zip/XYZ.app/Contents/jdk-11/bin/java",
"message": "Исполняемый файл не имеет защищенной среды выполнения.",
"docUrl": ноль,
"архитектура": "x86_64"
},

Похоже, что успешное нотариальное заверение, о котором сообщили другие, может быть связано с
Apple временно ослабила требования к нотариальному заверению
https://developer.apple.com/news/?id=09032019a до января 2020 года.

Я могу передать нашу копию журнала, если это будет полезно.

—
Вы получаете это, потому что вы прокомментировали.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/AdoptOpenJDK/openjdk-build/issues/1130?email_source=notifications&email_token=ALFWETDWY6UNPTKTOAOHGFLQSEDKHA5CNFSM4H3I6DJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN57W8EDBue2LOORPWSZGO
или отписаться
https://github.com/notifications/unsubscribe-auth/ALFWETGV56Q5HXDOMCPKBKTQSEDKHANCNFSM4H3I6DJQ
.

Apple выпустила обновление: https://developer.apple.com/news/?id=12232019a
Правильно ли я понимаю, что использование JDK8 в OS X 10.15 просто начнет полностью терпеть неудачу, начиная с 03 февраля (через 4 недели)?
Это было бы совсем плохо..

Apple выпустила обновление: https://developer.apple.com/news/?id=12232019a
Правильно ли я понимаю, что использование JDK8 в OS X 10.15 просто начнет полностью терпеть неудачу, начиная с 03 февраля (через 4 недели)?
Это было бы совсем плохо..

Нет, это не то, что произойдет. Это плохо, но то, что работает сейчас, будет работать и дальше. Чтобы подать приложение на нотариальное заверение, оно должно соответствовать ряду требований, одно из которых — подписание кода, другое — защита во время выполнения. Чтобы ваше приложение, загруженное из Интернета, было установлено на Catalina (10.15), оно должно пройти проверку привратника на предмет его надлежащего нотариального заверения. Это происходит прямо сейчас на Каталине.

Что происходит 3 февраля, так это то, что вы не можете нотариально заверить свое приложение в Apple, если оно не соответствует планке в отношении подписи кода и усиления защиты во время выполнения.

Apple сейчас находится в льготном периоде, так что вы можете представить ЧТО-НИБУДЬ, и они заверят это нотариально, даже если это не соответствует требованиям. После 3 февраля вы не сможете нотариально заверить приложение, поэтому вы не сможете распространять новое приложение без его прохождения. Конечно, в июле Apple сказала, что это будет сентябрь. В сентябре они говорили «январь», а в декабре теперь говорят «февраль». Таким образом, они признают, что что-то не так, и этим они навредят многим людям.

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

для тех, кто борется с усилением защиты во время выполнения, добавьте все шесть доступных разрешений plist и убедитесь, что ваша среда выполнения Java, какую бы версию вы ни использовали, находится в папке, которая будет подписана кодом при использовании параметра -deep (который есть в MacOS или фреймворки). Если вы поместили свою JRE в плагины, предполагается, что она была разработана третьей стороной, и не будет кодировать или укреплять это место. Любые другие места, кроме MacOS и Frameworks, кодирование игнорирует.

Даже если само подписание может сработать или не сработать, я не вижу, как кто-то извне может исправить следующий тип предупреждений о нотариальном заверении (который станет ошибкой и заблокирует все будущие нотариальные заверения 3 февраля):

"severity": "warning",
"code": null,
"path": "mydmg.dmg/MyApp.app/Contents/Helpers/jre_1.8.0_XX.jre/Contents/Home/lib/libzip.dylib",
"message": "The binary uses an SDK older than the 10.9 SDK.",
"docUrl": null,
"architecture": "x86_64"

Согласно https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution/resolving_common_notarization_issues , это ожидается, и двоичные файлы должны быть созданы в первую очередь с более новой версией.

Мы не можем просто прекратить выпускать обновления для нашего программного обеспечения для OS X 10.15+, начиная с 3 февраля, но в настоящее время похоже, что именно это и произойдет. приемлемый путь..

Мы не можем просто прекратить выпуск обновлений нашего программного обеспечения для OS X 10.15+.

FWIW наше решение состояло в том, чтобы собрать его самостоятельно с помощью более нового SDK через https://github.com/stooke/jdk8u-xcode10 .

Кажется, со вчерашнего дня все эти предупреждения о нотариальном заверении окончательно превратились в ошибки. Это означает, что мы больше не можем нотариально заверять наши Java-приложения :(

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

Логика нашего приложения содержится в файле jar. Этот JAR-файл позже объединяется в пакет приложения с помощью команды packagesbuild (http://s.sudre.free.fr/Software/Packages/about.html). Этот пакет также содержит AdoptOpenJDK JRE 11.0.4. Это означает, что мы отправляем эту версию с нашим приложением, чтобы убедиться, что наше приложение всегда запускается с требуемым.

Затем мы подписываем код следующим образом

# signing the main application
    codesign --deep --force --timestamp --strict --entitlements "${ENTITLEMENTS_DIR}" \
      --options runtime --sign "${CERT_DEV_ID_APPLICATION}" "${DIR_TO_OUR_APP_JAR}"

    # signing the java binaries
    find ${DIR_TO_JRE} -type f -exec \
      codesign --deep --force --timestamp --strict --entitlements "${ENTITLEMENTS_DIR}" \
      --options runtime --sign "${CERT_DEV_ID_APPLICATION}" '{}' \;

Конечно, все 6 разрешений есть, и они также будут видны после установки приложения.

Все работает нормально, пока не включена усиленная среда выполнения. Нотариальное заверение проходит, но приложение не может быть запущено с поставляемой java-версией. Это говорит

Произошла ошибка во время инициализации виртуальной машины Не удалось зарезервировать достаточно места в CodeHeap «не-nmethods» (2496 КБ)

Запуск приложения с предустановленной версией Java работает нормально.

Кажется, со вчерашнего дня все эти предупреждения о нотариальном заверении окончательно превратились в ошибки. Это означает, что мы больше не можем нотариально заверять наши Java-приложения :(

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

Я столкнулся с той же проблемой вчера. Сегодня все в порядке.

Я тоже видел это, возможно, это Apple пинала шины из-за более строгих правил, которые планируется ввести в действие 3 февраля.

При попытке нотариального заверения файлов jdk-13.0.1+9 в .jmod файлы обнаруживаются как не подписанные службой нотариального заверения Apple, например:

    {
      "severity": "warning",
      "code": null,
      "path": "[...]/Contents/Home/jmods/jdk.jartool.jmod/bin/jarsigner",
      "message": "The binary is not signed.",
      "docUrl": null,
      "architecture": "x86_64"
    },

Я вижу, что подпись jmod была удалена 21 августа в https://github.com/AdoptOpenJDK/openjdk-build/commit/5cd5306b4e97437aa2129dffd7e83e2f7cfd9255#diff -9a6d9f1628b9075aa2e1b4c33e4b9cc8 и все еще закомментирована. Упомянутый тикет https://github.com/AdoptOpenJDK/TSC/issues/107 был закрыт, есть ли планы вернуть его?

Произошла ошибка во время инициализации виртуальной машины Не удалось зарезервировать достаточно места в CodeHeap «не-nmethods» (2496 КБ)

После еще одного взгляда на это кажется, что проблема была в нашем скрипте. Исторически так сложилось, что мы дополнительно подписываем JRE. Теперь я просто удалил часть find-sign для JRE, и, похоже, это работает.

Как уже упоминал @abauman-7signal, все ошибки теперь снова являются предупреждениями, возможно, до 3 февраля.
Есть идеи, как нотариально заверить OpenJDK 13 и заставить его работать после этого?

Любой хороший способ исправить это сейчас? В macOS 10.15.2 и попытке использовать openjdk8

Я пытаюсь обобщить текущее состояние. Резюме может содержать ошибки, так как я не специалист в этой области. @gdams возглавляет усилия по нотариальному заверению AdoptOpenJDK и включению усиленной поддержки во время выполнения, но он занят этим. Так что относитесь к этому с недоверием…

Работа над JDK 11 с HotSpot завершена с JDK 11, за которым вскоре последует OpenJ9. Сборка JDK должна работать без проблем. Ожидается, что результат этой работы будет включен в ЦП следующего квартала (апрель 2020 г.). Будут ли перестроения 11.0.6, которые будут доступны раньше, с полным нотариальным заверением и усиленной поддержкой времени выполнения, пока не решено. Существующие бинарники уже нотариально заверены и должны без проблем работать после 3 февраля:

$ codesign -dvv ~/Downloads/jdk-11.0.6+10/Contents/Home/bin/java  
Executable=/Users/andreas/Downloads/jdk-11.0.6+10/Contents/Home/bin/java
Identifier=net.java.openjdk.cmd
Format=Mach-O thin (x86_64)
CodeDirectory v=20200 size=276 flags=0x0(none) hashes=4+2 location=embedded
Signature size=9038
Authority=Developer ID Application: London Jamocha Community CIC (VDX7B37674)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=15 Jan 2020 at 13:14:22
Info.plist entries=4
TeamIdentifier=VDX7B37674
Sealed Resources=none
Internal requirements count=1 size=180

JDK 8 все еще находится в стадии разработки, и ETA еще нет. Основная проблема здесь заключается в том, что JDK 8 поддерживает сборку только с более старыми кодами Xcode, которые, в свою очередь, не поддерживают нотариальное заверение и защищенную среду выполнения. В настоящее время предпринимаются попытки использовать более новые версии Xcode, но полученные двоичные файлы еще не проходят набор тестов. @gdams изучает это вместе с Apple. Существующие исполняемые файлы нотариально заверены и должны продолжать работать после 3 февраля:

$ codesign -dvv ~/Downloads/jdk8u242-b08/Contents/Home/bin/java
Executable=/Users/andreas/Downloads/jdk8u242-b08/Contents/Home/bin/java
Identifier=net.java.openjdk.cmd
Format=Mach-O thin (x86_64)
CodeDirectory v=20200 size=884 flags=0x0(none) hashes=23+2 location=embedded
Library validation warning=OS X SDK version before 10.9 does not support Library Validation
Signature size=9038
Authority=Developer ID Application: London Jamocha Community CIC (VDX7B37674)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=19 Jan 2020 at 16:38:24
Info.plist entries=4
TeamIdentifier=VDX7B37674
Sealed Resources=none
Internal requirements count=1 size=180

JDK 14, который будет выпущен в марте, должен иметь те же возможности, что и JDK 11. Вскоре должны быть доступны ночные сборки JDK 14 с нотариальным заверением и усиленной поддержкой среды выполнения. Для этого требуется как минимум https://github.com/AdoptOpenJDK/openjdk-build/pull/1517 .

Срок службы всех остальных JDK (9, 10, 12, 13) истек, и поэтому они не рассматриваются.

Спасибо за это обновление и вашу работу по устранению этой проблемы.

Пожалуйста, сделайте сборку 11.0.6 как можно скорее. В нынешнем виде я считаю, что такие разработчики, как мы, которые выпускают приложения со встроенной средой выполнения Java, не смогут выпустить новую сборку, работающую на Catalina, после 3 февраля до тех пор, пока через два месяца не будет выпущена версия 11.0.7. (Если только вам не удалось получить 11.0.4+11.2 до того, как он был удален, что мы и сделали.)

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

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

@mdgood , вы уже можете получить одну из наших ночных сборок JDK11 с более новыми обновленными обновлениями нотариального заверения. См . https://ci.adoptopenjdk.net/job/build-scripts/job/jobs/job/jdk11u/job/jdk11u-mac-x64-hotspot.

Мне было бы интересно посмотреть, как у тебя дела? Дайте мне знать!

@gdams Спасибо за подсказку - это отличная новость! Я возьму это и сообщу о наших результатах.

JDK 14, который будет выпущен в марте, должен иметь те же возможности, что и JDK 11. Вскоре должны быть доступны ночные сборки JDK 14 с нотариальным заверением и усиленной поддержкой среды выполнения. Для этого требуется как минимум #1517.

Срок службы всех остальных JDK (9, 10, 12, 13) истек, и поэтому они не рассматриваются.

Обратите внимание, что срок службы JDK 13 не истек. Он подойдет к концу только после выпуска JDK 14 в марте. Пересмотрите и выпустите еще одну нотариально заверенную сборку JDK 13, чтобы можно было иметь нотариально заверенную сборку последней версии JDK.

@gadams Ночная сборка 11.0.7 от 30 января у нас работает нормально. Сборка нашего приложения нотариально заверена без предупреждений, прекрасно устанавливается и работает на Catalina. Я попытаюсь снова создать и нотариально заверить наше приложение на следующей неделе после того, как вступят в силу новые ограничения, просто чтобы перепроверить.

Строительство и нотариальное заверение вчера также работали нормально.

По состоянию на 06:01:30 +0000 06:01:30 2020 г. я получаю такие ошибки нотариального заверения, как:

серьезность | "ошибка"
путь | "..../Содержание/Плагины/Java.Runtime/Содержание/Главная/jre/bin/java"
сообщение | «Двоичный файл использует SDK старше, чем SDK 10.9».
архитектура | "x86_64"

поэтому я предполагаю, что вы увидите ту же проблему в ближайшем будущем.

Есть ли прогресс или сроки для Java 8 JRE, созданной по сравнению с 10.9 или более поздней версией? Нам все еще нужно связать с Java 8 из-за изменений RMI.

Любая дополнительная информация будет очень полезна. Если все еще есть значительные препятствия, мы можем изучить возможность создания его самостоятельно с помощью этого репозитория, упомянутого ранее:
https://github.com/stooke/jdk8u-xcode10

Однако, если в ближайшие несколько дней будет доступна Java 8 JRE, я бы предпочел дождаться этого.

@addsomebass Ничего не предвидится. И если я правильно помню, один из членов нашей команды поигрался с патчами, на которые вы ссылаетесь, и получившиеся двоичные файлы не прошли набор тестов. Таким образом, вы бы связали JDK с известными дефектами.

@addsomebass Я работал с Apple над устранением сбоев тестов, упомянутых @aahlenst. Я повторю, что патчи в https://github.com/stooke/jdk8u-xcode10 не готовы к производству и имеют сбои при тестировании.

Моя текущая цель — подготовить нотариально заверенный бинарный файл jdk8 к концу месяца.

Спасибо за обновление @gdams , я очень ценю вашу работу над этим.

Спасибо всем за работу над этим - хотя у меня все еще есть проблема.

Я использую jpackage из последней версии EA JDK14 для создания файла .app. Файл имеет такую ​​структуру:

MyApp.app/
  Contents/
    MacOS/ <- the launcher
    Resources/
    PkgInfo
    Info.plist
    app/ <- the libs for the app
    runtime/ <- contents of jdk-11.0.7+2-jre

Проблема в том, что я могу:

• Создайте нотариально заверенное приложение, но оно не будет работать или
• Создайте работающее приложение, но оно не будет нотариально заверено

Чтобы отложить одну вещь - подписание приложений для Mac в jpackage в настоящее время не работает, поэтому я не могу его использовать. Это _было_ работает, когда среда выполнения не была подписана, но теперь ясно, что мне нужно сделать подпись самому.

Мне кажется, что я что-то неправильно понимаю о том, как включена среда выполнения (JRE) и требованиях для ее подписания.

Сначала я подписываю все файлы, не находящиеся в среде выполнения и не являющиеся лаунчерами:

% find my-app.app -type f -not -path "*/Contents/runtime/*" \
  -not -path "*/Contents/MacOS/my-app" \
  -not -path "*libapplauncher.dylib" \
  -exec codesign -v -s "my key" --prefix com.myapp. --keychain /Users/myuser/Library/Keychains/codesigning.keychain {} \;

Я полагал, что если среда выполнения уже подписана, повторное подписание не потребуется.

На данный момент мое приложение работает. Однако:

% spctl -a -t exec -vv my-app.app
my-app.app: code has no resources but signature indicates they must be present

Я не совсем уверен, что это значит - единственное, что я могу найти в Интернете, это то, что это может означать, что приложение повреждено. Это не очень много информации, чтобы продолжаться.

Итак, я пытаюсь:

% spctl -a -t exec -vv my-app.app/Contents/runtime 
my-app.app/Contents/runtime: code has no resources but signature indicates they must be present

Я не уверен, означает ли это, что источником проблемы является среда выполнения. Если я запущу ту же проверку исходного кода JRE (до того, как он был упакован jpackage), я получу тот же результат.

% codesign -vvv --deep --strict /path/to/jdk-11.0.7+2-jre 
/path/to/jdk-11.0.7+2-jre: code has no resources but signature indicates they must be present
% codesign -dv --deep --strict /path/to/osx/jdk-11.0.7+2-jre 
Executable=/path/to/jdk-11.0.7+2-jre/Contents/MacOS/libjli.dylib
Identifier=libjli
Format=bundle with Mach-O thin (x86_64)
CodeDirectory v=20500 size=786 flags=0x10000(runtime) hashes=16+5 location=embedded
Signature size=9038
Timestamp=8 Feb 2020 at 19:20:05
Info.plist=not bound
TeamIdentifier=VDX7B37674
Runtime Version=10.14.0
Sealed Resources=none
Internal requirements count=1 size=168

Итак, теперь я подписываю приложение:

codesign -f -s "my key" --options=runtime --prefix com.myapp. --keychain /Users/myuser/Library/Keychains/codesigning.keychain my-app.app

Я должен использовать --options=runtime , иначе я получаю сообщение об ошибке _Исполняемый файл не имеет усиленной среды выполнения_.

Проверьте еще раз:

% spctl -a -t exec -vv my-app.app
bliss-5.app: accepted
source=Developer ID
origin=Developer ID Application: D Gravell (366TU22RYQ)

Ура! Но если я проверю ту же папку runtime с JRE в ней, я все равно получу то же сообщение.

Это дает результат нотариального заверения:

      "path": "my-app.dmg/my-app.app/Contents/runtime/Contents/MacOS/libjli.dylib",
      "message": "The signature of the binary is invalid.",

Кроме того, приложение больше не работает:

% my-app.app/Contents/MacOS/my-app
2020-02-12 14:39:08.685 bliss[2909:61940] /private/tmp/my-app.app/Contents/MacOS/libapplauncher.dylib not found.

Затем я понял, что этот файл не был подписан (так почему spctl позволяет это???), и поэтому я подписываю его:

% codesign -f -s "My key" --options=runtime --prefix com.myapp. -vv --keychain /Users/gravelld/Library/Keychains/codesigning.keychain my-app.app/Contents/MacOS/libapplauncher.dylib
% codesign -vvv --deep --strict my-app/Contents/MacOS/libapplauncher.dylib
my-app.app/Contents/MacOS/libapplauncher.dylib: valid on disk
my-app.app/Contents/MacOS/libapplauncher.dylib: satisfies its Designated Requirement

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

Но он все еще не запускается, на этот раз из-за проблемы с JRE:

% my-app.app/Contents/MacOS/my-app
2020-02-12 14:45:51.846 my-app[2919:63060] Failed to find library.:/private/tmp/my-app.app/Contents/runtime/Contents/Home/lib/jli/libjli.dylib
2020-02-12 14:45:51.847 my-app[2919:63060] my-app:Failed to locate JLI_Launch
2020-02-12 14:45:51.847 my-app[2919:63060] my-app:Failed to launch JVM

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

% codesign -f -s "my key" --options=runtime --prefix com.myapp. -v --keychain /Users/gravelld/Library/Keychains/codesigning.keychain  my-app.app/Contents/runtime/Contents/Home/lib/jli/libjli.dylib
my-app.app/Contents/runtime/: replacing existing signature
my-app.app/Contents/runtime/: signed bundle with Mach-O thin (x86_64) [com.oracle.java.com.myapp]

И снова подпишите приложение, потому что приложение изменилось. Теперь я получаю эту красоту при беге:

% my-app.app/Contents/MacOS/my-app
Error: dl failure on line 542
Error: failed /private/tmp/my-app.app/Contents/runtime/Contents/Home//lib/server/libjvm.dylib, because dlopen(/private/tmp/my-app.app/Contents/runtime/Contents/Home//lib/server/libjvm.dylib, 10): no suitable image found.  Did find:
    /private/tmp/my-app.app/Contents/runtime/Contents/Home//lib/server/libjvm.dylib: code signature in (/private/tmp/my-app.app/Contents/runtime/Contents/Home//lib/server/libjvm.dylib) not valid for use in process using Library Validation: mapping process and mapped file (non-platform) have different Team IDs
2020-02-12 14:53:03.153 my-app[2942:64467] my-app:Failed to launch JVM

Однако это все еще не заверяется нотариально:

      "path": "my-app.dmg/my-app.app/Contents/runtime/Contents/MacOS/libjli.dylib",
      "message": "The signature of the binary is invalid.",

Конечно же:

% codesign -vvv --deep --strict my-app.app/Contents/runtime/Contents/MacOS/libjli.dylib 
my-app.app/Contents/runtime/Contents/MacOS/libjli.dylib: a sealed resource is missing or invalid
file modified: /private/tmp/my-app.app/Contents/runtime/Contents/Home/lib/jli/libjli.dylib

Ах, я помню, я подписал runtime/Contents/Home/lib/jli/libjli.dylib , поэтому мне нужно снова подписать пакет runtime , а затем пакет приложения-обертки.

Итак, мои вопросы:

• Должен ли я повторно подписывать среду выполнения?
• Я использую правильную среду выполнения?
• Может ли кто-нибудь поделиться своими успешными структурами приложений?

Привет!

Мне удалось запустить его с помощью JDK 14, jpackage и подписав все dylibs и jar-файлы самостоятельно. Вы установили эти строки в файле прав?

<key>com.apple.security.cs.allow-jit</key>
<true/>
<key>com.apple.security.cs.allow-unsigned-executable-memory</key>
<true/>
<key>com.apple.security.cs.disable-executable-page-protection</key>
<true/>
<key>com.apple.security.cs.disable-library-validation</key>
<true/>
<key>com.apple.security.cs.allow-dyld-environment-variables</key>

Это права для среды выполнения или для приложения, которое связывает среду выполнения?

Я использовал его для всех команд codesign, например, для dmg, а также для всех других файлов (dylib, jar, .app):

codesign --timestamp --entitlements src/main/deploy/package/macosx/MyApp.entitlements --options runtime --deep -vvv -f --sign "Developer ID Application: John Public (XXXXXXXXXX)" MyApp-1.0.dmg

@ dg76 спасибо - попробую. До сих пор я не писал никаких прав, но с 3 февраля все, кажется, сломалось; возможно, я полагался на значение по умолчанию, которое раньше было приемлемым, но теперь это не так (очевидно, это относится к усиленной среде выполнения и сборкам против старых SDK, поэтому я пытаюсь принять эту сборку).

Кажется, это работает, спасибо! Итак, чтобы задокументировать мое конечное решение:

% security unlock-keychain -p passwordhere codesigning.keychain
% find my-app.app -type f \
  -not -path "*/Contents/runtime/*" \
  -not -path "*/Contents/MacOS/my-app" \
  -not -path "*libapplauncher.dylib" \
  -exec codesign --timestamp --entitlements /tmp/bliss.entitlements -s "XXX" --prefix com.myapp. --options runtime -v --keychain /path/to/codesigning.keychain {} \;

% find my-app.app/Contents/runtime -type f \
  -not -path "*/legal/*" \
  -not -path "*/man/*" \
  -exec codesign -f --timestamp --entitlements /tmp/bliss.entitlements -s "XXX" --prefix com.myapp. --options runtime -v --keychain /path/to/codesigning.keychain {} \;

% codesign -f --timestamp --entitlements /tmp/bliss.entitlements -s "XXX" --prefix com.myapp. --options runtime -v --keychain /path/to/codesigning.keychain my-app.app/Contents/runtime

% codesign -f --timestamp --entitlements /tmp/bliss.entitlements -s "XXX" --prefix com.myapp. --options runtime -v --keychain /path/to/codesigning.keychain my-app.app

Все тесты работают:

% codesign -vvv --deep --strict my-app.app/Contents/runtime 
my-app.app/Contents/runtime: valid on disk
my-app.app/Contents/runtime: satisfies its Designated Requirement
% codesign -vvv --deep --strict my-app.app/                
--prepared:/private/tmp/my-app.app/Contents/MacOS/libapplauncher.dylib
--validated:/private/tmp/my-app.app/Contents/MacOS/libapplauncher.dylib
my-app.app/: valid on disk
my-app.app/: satisfies its Designated Requirement
% spctl -a -t exec -vv my-app.app          
my-app.app: accepted
source=Developer ID
origin=XXX

Это работает?

% my-app.app/Contents/MacOS/my-app 

Да!

Нотариально заверяет?

Status: success
Status Code: 0
Status Message: Package Approved

Ура!

Резюме для тех, кто связывает JRE:

• Подписание jpackage сейчас нарушено, если вы хотите что-то нотариально заверить
• Вы должны подписать свой код.
• Вы должны повторно подписать JRE. Используйте -f для принудительной подписи.
• Вы должны указывать права во всех вызовах подписи

Привет, могу я просто спросить, есть ли у нас в настоящее время сборка Mac для Java 8 или Java 9, которая позволяет нотариально заверить ее в соответствии с новыми правилами или нет?

@ijabz , если я правильно понимаю ваш вопрос, вы хотите связать jvm с приложением, а затем нотариально заверить это. В настоящее время вы не можете. Последняя сборка AdoptOpenJDK создана с использованием более старой версии пакета SDK для Mac OS и не может быть переупакована и повторно нотариально заверена.

Если вы просто хотите установить Java, последние установщики .pkg будут работать на OSX Catalina, и я могу установить и запустить Java без проблем. Эти установщики были нотариально заверены и могут без проблем установить Java на ваш компьютер.

gadams работает над нотариально заверенной сборкой Java 8 и надеется сделать это в конце месяца. Желаю ему и всем остальным удачи.

если я правильно понимаю ваш вопрос, вы хотите связать jvm с приложением, а затем нотариально заверить это. В настоящее время вы не можете

Да, правильно, это потребует изменений кода с моей стороны, но работает ли сборка AdoptOpenJDK Java 11?

Или, если я установлю сборки Oracle, это будет работать, в настоящее время я использую Oracle Java 8 на MacOS, и это работало до 3 февраля, это то, что вы подразумеваете под сборкой .pkg?

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

@ijabz Извините, я не могу говорить о Java 11 или более поздней версии, так как я не работал с ней лично. Судя по комментариям здесь вроде как есть способ получить рабочий бандл. Я могу говорить только о работе со сборками Java 8.

Пакеты установщика Mac или файлы .pkg представляют собой установщики программного обеспечения. В настоящее время есть несколько установщиков .pkg, доступных для сборок AdoptOpenJDK, которые нотариально заверены и правильно установят Java, например этот здесь:
https://github.com/AdoptOpenJDK/openjdk8-binaries/releases/download/jdk8u242-b08/OpenJDK8U-jdk_x64_mac_hotspot_8u242b08.pkg

Я чувствую себя глупым, но я не понимаю, что, с одной стороны, AdoptOpenJDk работает над нотариально заверенной сборкой Java 8, которая не будет готова до конца месяца, но, с другой стороны, уже есть установщик AdoptOpenJDk Java 8, который уже установит нотариально заверенная версия Java 8?

@ijabz Я думаю, причина в том, что если что-то было нотариально заверено до 3 февраля 2020 года, оно все еще действительно и работает на macOS Catalina. Однако повторно нотариально заверить его сейчас не получится, потому что теперь правила более строгие. Таким образом, установщик AdoptOpenJDK Java 8, вероятно, был нотариально заверен до 3 февраля и, следовательно, все еще может использоваться.

Но вы больше не можете его упаковать, потому что с 3 февраля Apple требует, чтобы приложения были «защищены», для чего требуется XCode 10. А Java 8 не была скомпилирована с XCode 10, поэтому ее нельзя укрепить (пока).

Таким образом, вы можете установить AdoptOpenJDK Java 8, несмотря на то, что он не защищен, только потому, что он был нотариально заверен до 3 февраля. Но теперь было бы невозможно создать новую его версию или упаковать с ней программу, потому что она не может быть усилена и, следовательно, не может быть нотариально заверена.

Из того, что я прочитал, по крайней мере, JDK 11.0.7 и JDK 14 работают нормально, скомпилированы с использованием XCode 10, «укреплены», и по крайней мере JDK 14 можно использовать для упаковки программ.

Хорошо, спасибо, теперь я понимаю лучше.
Еще одна вещь, когда вы ссылаетесь на JDK 11.0.7 и JDK 14, я предполагаю, что вы имеете в виду сборки AdoptOpenJDk, ситуация для сборок AdoptOpenJDk такая же, как и для загрузок, доступных на сайте Oracle?

Извините, я не знаю. Я пробовал это только с OpenJDK (не с AdoptOpenJDK, а с другим дистрибутивом, но я думаю, что он одинаков для всех дистрибутивов OpenJDK). Однако, поскольку кажется, что для совместимости с XCode 10 требуются изменения в JDK 8, и, насколько мне известно, Oracle вносит те же изменения в OpenJDK и свой собственный дистрибутив, я думаю, что их JDK 8 также не усилен ( в противном случае они выпустили бы версию Java 8 для OpenJDK, которая также была бы усилена). Но, как я уже сказал, я не пробовал.

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

@ijabz Oracle JDK можно использовать бесплатно только в ограниченном наборе случаев (см. FAQ по лицензированию Oracle Java SE ). Сборки OpenJDK от Oracle также доступны и по-прежнему бесплатны для использования без ограничений, но количество поддерживаемых платформ и версий значительно меньше, чем то, что мы предлагаем здесь, в AdoptOpenJDK. Как следует из названия, AdoptOpenJDK — это сборки OpenJDK. Одна из наших основных задач — продвигать все изменения. Другие поставщики OpenJDK (а их много: Amazon, Azul, BellSoft, SAP,…) могут иметь другие политики.

Верно, и я вижу, что сейчас они предлагают сборку MacOS только для последних сборок, хорошо, спасибо.

@gdams , вы все еще ожидаете, что к концу месяца будет готов нотариально заверенный двоичный файл jdk8? Кроме того, будет ли это включать JVM J9?

@gdams , вы все еще ожидаете, что к концу месяца будет готов нотариально заверенный двоичный файл jdk8? Кроме того, будет ли это включать JVM J9?

Можете ли вы попробовать дистрибутив BellSoft JDK8 (https://bell-sw.com/pages/java-8u242/). Я заменил AdoptOpenJDK J8 на BellSoft J8, избавился от "The binary uses an SDK older than the 10.9 SDK." и, наконец, получил нотариальное заверение.

Похоже, BellSoft J8 уже нотариально заверена.

Насколько я понимаю, BellSoft JDK не бесплатен.

Насколько я понимаю, BellSoft JDK не бесплатен.

Стандартная общественная лицензия GNU (GPL) с "CLASSPATH" ИСКЛЮЧЕНИЕМ GPL
для Regular Liberica Java SE 8u242 JDK или JRE та же лицензия, что и для OpenJDK.

Они предлагают коммерческую поддержку, если вам нужно.

Спасибо за разъяснение !

Кажется, это работает, спасибо! Итак, чтобы задокументировать мое конечное решение:

% security unlock-keychain -p passwordhere codesigning.keychain
% find my-app.app -type f \
  -not -path "*/Contents/runtime/*" \
  -not -path "*/Contents/MacOS/my-app" \
  -not -path "*libapplauncher.dylib" \
  -exec codesign --timestamp --entitlements /tmp/bliss.entitlements -s "XXX" --prefix com.myapp. --options runtime -v --keychain /path/to/codesigning.keychain {} \;

% find my-app.app/Contents/runtime -type f \
  -not -path "*/legal/*" \
  -not -path "*/man/*" \
  -exec codesign -f --timestamp --entitlements /tmp/bliss.entitlements -s "XXX" --prefix com.myapp. --options runtime -v --keychain /path/to/codesigning.keychain {} \;

% codesign -f --timestamp --entitlements /tmp/bliss.entitlements -s "XXX" --prefix com.myapp. --options runtime -v --keychain /path/to/codesigning.keychain my-app.app/Contents/runtime

% codesign -f --timestamp --entitlements /tmp/bliss.entitlements -s "XXX" --prefix com.myapp. --options runtime -v --keychain /path/to/codesigning.keychain my-app.app

Все тесты работают:

% codesign -vvv --deep --strict my-app.app/Contents/runtime 
my-app.app/Contents/runtime: valid on disk
my-app.app/Contents/runtime: satisfies its Designated Requirement
% codesign -vvv --deep --strict my-app.app/                
--prepared:/private/tmp/my-app.app/Contents/MacOS/libapplauncher.dylib
--validated:/private/tmp/my-app.app/Contents/MacOS/libapplauncher.dylib
my-app.app/: valid on disk
my-app.app/: satisfies its Designated Requirement
% spctl -a -t exec -vv my-app.app          
my-app.app: accepted
source=Developer ID
origin=XXX

Это работает?

% my-app.app/Contents/MacOS/my-app 

Да!

Нотариально заверяет?

Status: success
Status Code: 0
Status Message: Package Approved

Ура!

Резюме для тех, кто связывает JRE:

• Подписание jpackage сейчас нарушено, если вы хотите что-то нотариально заверить
• Вы должны подписать свой код.
• Вы должны повторно подписать JRE. Используйте -f для принудительной подписи.
• Вы должны указывать права во всех вызовах подписи

Я смог выполнить ваши шаги, однако у меня есть библиотека и даже с
<key>com.apple.security.cs.disable-library-validation</key> <true/>

Я получаю эту ошибку:

Исключение в потоке «Поток приложения JavaFX» java.lang.UnsatisfiedLinkError: /private/var/folders/0f/trlp6tp95qjbzm99ds8pt8zm0000gp/T/JxBrowser/7.5/libbrowsercore_toolkit.dylib: dlopen(/private/var/folders/0f/trlp6tp95qjpm/Tjbzm99ds0008zm99ds0008zm JxBrowser/7.5/libbrowsercore_toolkit.dylib, 1): не найдено подходящего образа. Нашел:
/private/var/folders/0f/trlp6tp95qjbzm99ds8pt8zm0000gp/T/JxBrowser/7.5/libbrowsercore_toolkit.dylib: подпись кода в (/private/var/folders/0f/trlp6tp95qjbzm99ds8pt8zm0000gp/T/JxBrowser/7.5/libbrowsercore_tool) не использовать для libbrowsercore_tool. в процессе с использованием проверки библиотеки: процесс сопоставления и сопоставленный файл (не платформенный) имеют разные идентификаторы группы

Означает ли это, что моей библиотеке также необходимо это право для работы, или это что-то с моей стороны?

Самая разочаровывающая часть процесса нотариального заверения заключается в том, что мне пришлось встроить этот процесс выпуска в конвейер CI/CD. Я бы хотел, чтобы Apple предоставила тестовую конечную точку. Мне не нужно его нотариальное заверение, мне просто нужно знать, подлежит ли оно нотариальному заверению. Конечно, разница небольшая, но пара вещей делает ее неудобной.

1. Если я использую обновление для третьей стороны, мне нужен процесс приема, который подтверждает, что обновление подлежит нотариальному заверению. Отправив эту третью сторону на проверку, я теперь нотариально заверил эту третью сторону, используя кредиты моей компании, и мои специалисты по безопасности считают, что это не здорово.
2. Я каждый день отправляю на нотариальное заверение вещи, которые абсолютно не собираюсь предоставлять клиенту, и мне приходится использовать учетные данные, которые уполномочены делать больше, чем просто тестировать. Поскольку эти учетные данные теперь являются частью моего пайплайна, моя зона безопасности для взлома учетных данных стала больше. Поэтому мне нужна тестовая конечная точка, которая не использует кредиты или использует кредиты только для целей тестирования.

Кто-нибудь еще сталкивается с проблемой, которая у меня есть @gravelld @dg76 Я пытался создать право, но это, похоже, не отключает проверку библиотеки

@ dcboy95 Извините, я не знаю, как работают определенные права в отношении охвата всего пакета. Я обнаружил, что с подписанием кода мне пришлось отказаться от всей библиотеки, с которой я поставлялся, так что, может быть, это означает, что вся кодовая база, с которой вы поставляетесь, также должна иметь право? Извиняюсь.

@ dcboy95 Я думаю, вам просто нужно отказаться от файла «libbrowsercore_toolkit.dylib», используя код и ваш собственный сертификат. (Я думал, что уже размещал это предложение здесь, но не могу найти никакого ответа от себя.) Ошибка просто указывает на то, что библиотека имеет другую подпись, чем остальная часть приложения. И я думаю, что все должно иметь одинаковую подпись, чтобы гарантировать, что никто другой не вставит туда ничего. Так что просто попробуйте запустить codesign на "libbrowsercore_toolkit.dylib". Это исправит?

@ dg76 К сожалению, это не сработало. Со сторонней библиотекой он переустанавливается, если есть другая версия. Поэтому, когда я кодирую этот файл, он видит его как старый файл и загружает новый, заменяя измененный. В результате та же ошибка. Я думал, что право com.apple.security.cs.disable-library-validation решит эту проблему, но, похоже, это не так.

@ dcboy95 Думаю, это не сработает. Я думаю, что цель системы нотариального заверения Apple состоит в том, чтобы гарантировать, что разработчик подтвердил, что все части его приложения были протестированы и в порядке. Загрузка частей от других разработчиков во время выполнения, которые не были протестированы и подтверждены разработчиком, вероятно, не разрешена. Нельзя ли просто отключить функцию автоматической загрузки?

@ dg76 Спасибо за информацию, мне придется изучить их документацию, чтобы узнать, возможно ли это. Спасибо еще раз

Вышел AdoptOpenJDK 14+36 , полностью нотариально заверенный. Пожалуйста, сообщите в случае возникновения проблем.

Полностью нотариально заверенный JDK 8 все еще находится в разработке. Мы надеемся включить это в следующий квартальный ЦП (ближайший вторник к 17 апреля).

Требуемые исправления прошли несколько тестовых прогонов (включая TCK), но необходима дополнительная проверка. @gdams планирует опубликовать текущее состояние, чтобы мы могли предоставить сборки для тестирования в не столь отдаленном будущем.

@aahlenst есть ли планы на JDK 11?

@ dcboy95 Полностью нотариально заверенный JDK 11 будет опубликован как часть следующего ежеквартального ЦП (вскоре после ближайшего вторника к 17 апреля, если я правильно помню правило Oracle). А пока вы можете получить ночную сборку JDK 11 на https://adoptopenjdk.net/nightly.html?variant=openjdk11&jvmVariant=hotspot и сообщить, если она не работает.

Привет, я пытался использовать jdk-11.0.7 + 7 для установщика, но все равно [1] не работает с ошибкой «Подпись двоичного файла недействительна»

[1] /Contents/MacOS/libjli.dylib

@NishikaDeSilva попробуйте запустить это:

codesign --verbose=4 --deep --force -s "Developer ID Application: MyTeam (XXXX)" installer.jdk

@gdams Я попробовал ваше решение.

команда: codesign --verbose=4 --deep --force -s «Приложение ID разработчика: abc (xxxxx)» jdk-11.0.7+7

выход:
jdk-11.0.7+7: замена существующей подписи
jdk-11.0.7+7: вилка ресурсов, информация Finder или подобный мусор не разрешены

Но это указывает на следующую ошибку...
jdk-11.0.7+7: в коде нет ресурсов, но подпись указывает, что они должны присутствовать.

Я делаю что-то неправильно ?

Пробовал 11.0.7+7 из ночного билда. Нотариальное заверение проходит и заявка идет успешно. Однако кажется, что двоичные файлы (dylib) теперь ищутся в выполняемом пакете jar только любой собственной загрузкой, используемой JNA. В результате наше приложение теперь получает UnsatisfiedLinkErrors при попытке доступа к dylib, установленному в системе. Это работало раньше.

@MoxxiManagarm Подписаны ли дилибы? Проверьте с помощью codesign -v -v /path/to/dylib .

@aahlenst Я сомневаюсь, что это сторонние dylibs (драйверы устройств), установленные в системе, они не являются частью нашего приложения. У меня также есть активные права com.apple.security.cs.disable-library-validation , это не должно быть проблемой.

Библиотека находится в каталоге /usr/local/lib/

Используя ночную сборку JRE JDK 11, у меня возникла та же проблема, что и у NishikaDeSilva. Я тестировал ночные сборки JRE 13 и 14, а также на всякий случай.

Я не знаю, будет ли что-то из этого полезным, но вот мои заметки.

Запуск codesign -dvvv libjli.dylib для проверки подписи приводит к этому.

Executable=[...]/Contents/MacOS/libjli.dylib
Identifier=libjli
Format=bundle with Mach-O thin (x86_64)
CodeDirectory v=20500 size=786 flags=0x10000(runtime) hashes=16+5 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha1=512c6006363d2928665d9d135f360f974fe66d27
CandidateCDHashFull sha1=512c6006363d2928665d9d135f360f974fe66d27
CandidateCDHash sha256=1157d57e9849eb161251e3a4bca6e2ab7200eaa1
CandidateCDHashFull sha256=1157d57e9849eb161251e3a4bca6e2ab7200eaa11cf4d1f13ae558f0a8ae207e
Hash choices=sha1,sha256
CMSDigest=2727b2d669fee540fd5848fffba07d583d737065d4f28c205530b29f44dfb347
CMSDigestType=2
CDHash=1157d57e9849eb161251e3a4bca6e2ab7200eaa1
Signature size=9037
Authority=Developer ID Application: London Jamocha Community CIC (VDX7B37674)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Mar 31, 2020 at 8:44:15 AM
Info.plist=not bound
TeamIdentifier=VDX7B37674
Runtime Version=10.14.0
Sealed Resources=none
Internal requirements count=1 size=168

Проверка подписи с помощью spctl -a -vv libjli.dylib приводит к следующему:
libjli.dylib: code has no resources but signature indicates they must be present

Я не могу найти никакой хорошей документации по этой ошибке, но, похоже, это как-то связано с «запечатанными ресурсами», которые, как указано в подписи выше, равны none . Не имеет особого смысла.

Попытка кодировать файл самостоятельно приводит к следующему:
resource fork, Finder information, or similar detritus not allowed

Во всей существующей документации по этой ошибке говорится, что она вызвана расширенными атрибутами файла. В частности, com.apple.FinderInfo и com.apple.ResourceFork . Но ls -l@ libjli.dylib и xattr -l libjli.dylib не содержат x-атрибутов.

Любопытно, что перемещение файла в другое место (любое место за пределами папки Contents/MacOS ) или изменение расширения файла на что-то другое, кроме .dylib , сделает кодирование и проверку подписи нормальным, без каких-либо из вышеперечисленных бессмысленных действий. ошибки. Механизм кодирования также должен учитывать расположение файла, что приводит к тому, что он отличается от результатов файла в Contents/Home/lib/jli/libjli.dylib .

Любое обновление dylib драйвера, которое не найдено в течение /usr/local/lib/ после нотариального заверения (ночная сборка)?

Проверка подписи с помощью spctl -a -vv libjli.dylib приводит к следующему:
libjli.dylib: в коде нет ресурсов, но подпись указывает, что они должны присутствовать

@justin-espedal попробуйте запустить это в каталоге верхнего уровня:

xattr -cr .
codesign --verbose=4 --deep --force -s "Developer ID Application: MyTeam (XXXX)" adoptopenjdk-11.jdk 

выход:
jdk-11.0.7+7: замена существующей подписи
jdk-11.0.7+7: вилка ресурсов, информация Finder или подобный мусор не разрешены

@NishikaDeSilva запустите это в каталоге перед запуском команды codesign:

xattr -cr .

Это работает. Нет необходимости в рекурсивном -cr , достаточно просто удалить com.apple.FinderInfo из папки верхнего уровня. Имеет смысл, что атрибут FinderInfo в папке верхнего уровня мешает кодированию всего пакета.

Независимо от того, присутствует ли этот xattr или нет, libjli.dylib по-прежнему не может быть кодирован сам по себе. Требует ли механизм кодирования наличия dylib в этом конкретном месте для проверки чего-либо с помощью подписи кода содержащего пакета? Если это так (или, возможно, независимо от этого), почему весь пакет по умолчанию просто не кодируется?

Я бы, конечно, предпочел не кодировать весь код JRE, если в этом нет необходимости.

@gadams @aahlenst Какие-нибудь новости о нотариально заверенном JDK 1.8? Мы выпустим его 17 апреля? Есть ли более ранний набор, чтобы попробовать?

На следующей неделе сначала будет 8u252 без нотариального заверения и усиленной среды выполнения. После этого мы перевернем переключатели и создадим его с нотариальным заверением и усиленной средой выполнения. Дополнительная информация будет следовать. Я не знаю, есть ли уже бинарник, готовый для тестирования другими.

Будет ли 8u252 включать libAppleScriptEngine.dylib, созданный для более позднего SDK, поэтому он не выйдет из строя с помощью «Двоичный файл использует SDK старше, чем SDK 10.9», это было бы наиболее полезно, https://stackoverflow.com/questions/61208189/java-notarization -of-libapplescriptengine-dylib-failing-with-the-binary-uses-an

Вышел долгожданный 8u252, но оказалось, что почти все бинарники в нем все-таки собраны с sdk 10.8, что мешает успешному нотариальному заверению.
JRE с https://ci.adoptopenjdk.net/view/work%20in%20progress/job/jdk8u-mac-x64-hotspot-notarized/10/ содержала 10.14 двоичных файлов, поэтому мы надеялись, что официальный 8u252 тоже будет.

На следующей неделе сначала будет 8u252 без нотариального заверения и усиленной среды выполнения. После этого мы перевернем переключатели и создадим его с нотариальным заверением и усиленной средой выполнения.

Ребята, у вас есть расписание, которым вы можете поделиться, пожалуйста?

@meshcow Трудно оценить. Вот почему я не дал никакой оценки в первую очередь. Конвейеры с обычными сборками все еще работают (например, 14.0.1 с HotSpot и 11.0.7 с OpenJ9). Версия с усиленной средой выполнения будет построена позже.

@meshcow - мы будем создавать 8u252.1 для тестирования нашего патча для нотариального заверения Mac O, он должен быть здесь через день или два.

К вашему сведению, я использовал BellSoft 8u252, чтобы попытаться получить libAppleScriptEngine.dylib, который создан для более позднего SDK, чтобы разрешить нотариальное заверение, и могу подтвердить, что это сработало.

Также могу подтвердить, что я включил сборку JRE AdoptJDk 11.0.7 в свое приложение и успешно нотариально заверил свое приложение.

К вашему сведению, я использовал BellSoft 8u252, чтобы попытаться получить libAppleScriptEngine.dylib, который создан для более позднего SDK, чтобы разрешить нотариальное заверение, и могу подтвердить, что это сработало.

Не могли бы вы рассказать, пожалуйста, что вы используете для связывания jre с вашим приложением? Когда я использую javapackager, он говорит fxbundlerpath/Contents/MacOS/libpackager.dylib: is already signed .
А как вы это делаете с AdoptJDK 11?

Я использовал Appbundler (форк InfinityKind) - https://github.com/TheInfiniteKind/appbundler/
Я постараюсь завтра опубликовать полный подробный ответ на stackoveflow.

@as1an Добавлен ответ на мой собственный вопрос по адресу https://stackoverflow.com/questions/58548736/notarize-existing-java-application-for-macos-catalina .

У кого-нибудь есть нотариально заверенная сборка J9 JVM 1.8 для тестирования?

@meshcow Трудно оценить. Вот почему я не дал никакой оценки в первую очередь. Конвейеры с обычными сборками все еще работают (например, 14.0.1 с HotSpot и 11.0.7 с OpenJ9). Версия с усиленной средой выполнения будет построена позже.

@aahlenst Будет ли это включать версию 1.8 JVM для J9?

Это будет на этой неделе.

Большое спасибо!

Сегодня был выпущен нотариально заверенный бинарный файл JDK8u Hotspot jdk8u252-b09.1

https://adoptopenjdk.net/archive.html?variant=openjdk8&jvmVariant=горячая точка

Попробуйте и дайте нам знать, если у вас возникнут проблемы!

OpenJ9 также скоро выйдет

Мы смогли успешно нотариально заверить наше приложение со встроенной точкой доступа 8u252-b09.1 JRE.
Большое спасибо, ребята!

@meshcow Ваше приложение встраивает JVM или использует его извне? Мы видим проблему во время выполнения, говорящую о том, что подпись в JVM отличается от подписи нашего приложения.

@meshcow Ваше приложение встраивает JVM или использует его извне? Мы видим проблему во время выполнения, говорящую о том, что подпись в JVM отличается от подписи нашего приложения.

Встроена JVM (JNI), приложение подписано нашим сертификатом. В JRE мы ничего не подписывали, так как в ней все уже было подписано.
Пока проблем нет.

@meshcow Я знаю, что это не связано, и я прошу прощения, если это не тот форум для этого, но я изо всех сил пытался заставить JNI работать в связанном приложении, и мне было интересно, не могли бы вы поделиться какими-либо ресурсами, которые помогли вам туда добраться . Все текущие сборщики приложений Java, которые я могу найти, создают незащищенный исполняемый файл, который предотвращает нотариальное заверение, даже если JRE подлежит нотариальному заверению.

Любая помощь в преодолении этого последнего препятствия будет высоко оценена.

@addsomebass — мы используем стандартный общепринятый подход: небольшой модуль запуска, написанный на Objective C, который использует Java Invocation API для загрузки JVM и запуска с его помощью нашего [чистого] Java-приложения. Средство запуска помещается в каталог приложения OSX в /Contents/MacOs. JRE помещается в папку приложения Java в папке /Contents/[app-name]/jre.
Приложение OSX подписывается, после чего оно готово к отправке на нотаризацию. Мы используем следующие аргументы строки cmd для кода: --strict --timestamp --entitlements entitlements.plist --force --deep --options runtime , а содержимое entitlemenst.plist такое же, как в этом ответе: https://stackoverflow.com/a/58553559.

Так что единственное, что я могу посоветовать, это создать свой собственный лаунчер. Это не должно быть так сложно, есть много примеров, которые вы можете найти, например, https://github.com/search?l=Objective-C&q=JNI_createJavaVM&type=Code

@addsomebass Думаю, тебе не нужен собственный лаунчер. Я использую JNI в обычной программе Java, которая связана с использованием jpackage Java 14. Вы можете найти мои шаги здесь: https://blog.dgunia.de/2020/02/12/signed-macos-programs- with-java-14/ Он описывает только подписание, а не часть JNI. Но я создал обычный файл dylib JNI, который также подписывается во время этого процесса. Пока работает нормально, удалось нотариально заверить.

@addsomebass @dg76 В нашем случае Java 8, а не 14

@meshcow @dg76 спасибо за советы. Нам также нужно использовать Java 8 из-за изменений RMI.

Спасибо за поддержку нотариального заверения сейчас. Но где javapackager в пакете? Я могу найти только «нормальную» сборку jdk8 без javapackager. Есть ли полный jdk со встроенным javapackager?

@gdams @aahlenst
Мы использовали усиленную версию Open J9, выпущенную на прошлой неделе, и получили эту ошибку от Apple во время нотариального заверения:

{ "серьезность": "ошибка", "код": ноль, "путь": "/jre/Contents/MacOS/libjli.dylib", "message": "Подпись двоичного файла недействительна", "docUrl": null, "architecture": "x86_64" }

Он говорит, что у libjli.dylib нет подписи, но я полагаю, что это файл ссылки?

Мы также пробовали эту команду

Скачанный файл - OpenJDK8U-jre_x64_mac_openj9_macosXL_8u252b09_openj9-0.20.0.tar.gz* разархивировал его в папку jdk8u252-b09-jre-j9 и затем проверил подпись -

codesign -vvvv jdk8u252-b09-jre-j9jdk8u252-b09-jre-j9/: код не имеет ресурсов, но подпись указывает, что они должны присутствовать

Не уверен, что оба связаны. Это можно как-то исправить?

Спасибо.

Если вам нужна помощь, пожалуйста, откройте вопросы в https://github.com/adoptopenjdk/openjdk-support/.