Я отвечаю на этот вопрос по поводу Java-проекта, требующего нотариального заверения. С небольшими изменениями ответ должен работать и для других типов проектов (python, powershell, node).

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

Подпись кода

• Для стандартного Java-приложения (.pkg или .app, содержащего скрипты, jar-файлы) нотариальное заверение должно пройти. Во время нотариального заверения Apple извлечет .jar и выполнит поиск собственных библиотек. Если он найдет неподписанный, он будет отклонен. Если нет, все в порядке. Инструкции по нотариальному заверению с использованием xcrun приведены ниже.

• Для приложения Java, которое содержит собственные вызовы (например, JNI) к связанным библиотекам (.dylib, .jnilib), каждая связанная библиотека должна быть подписана с использованием сертификата «Приложения» (например, developerID_application.cer).

  • Certificates, Identifiers & Profiles, (Click "iOS, tvOS, watchOS" dropdown) macOS, Developer ID Application. (may also say "with Kext").
  • Если у вас нет этого сертификата, вам нужно запросить его с помощью CSR. В моем случае у меня изначально был только сертификат для установщиков упаковки (а не кодовая подпись). Этот процесс может оказаться сложным, особенно если вы используете один и тот же закрытый ключ для двух сертификатов. Если вы застряли, используйте openssl через командную строку (вместо Keychain Access).

  • После получения сертификата подписать каждую собственную библиотеку .dylib|.jnilib|.so|bin становится непросто. Общая идея состоит в том, чтобы использовать команду codesign против собственной библиотеки, чтобы она была подписана вами, разработчиком. Синтаксис:

    xargs codesign -s "P6DMU6694X" -v dependency.dylib

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

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

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

• После подписания собственных библиотек пакет необходимо отправить на нотариальное заверение с использованием xcrun.

  xcrun altool --eval-app --primary-bundle-id <bundle id> -u <iTunes Connect Account> -f <file path>

  Which may look something like this:

  xcrun altool --eval-app --primary-bundle-id com.domain.appname -u [email protected] -f appname.pkg

• Вам будет предложено ввести пароль разработчика Apple (НЕ пароль, который вы используете для входа на свой Mac). Изменить: поскольку требуется двойной фактор, вам необходимо создать пароль приложения для этого шага!

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

  RequestUUID = a1b2c3d4e5-a1b2-a1b2-a1b2-a1b2c3d4e5f6

• Периодически проверяйте статус этого уникального идентификатора, чтобы видеть, был ли он одобрен или отклонен.

  xcrun altool --eval-info a1b2c3d4e5-a1b2-a1b2-a1b2-a1b2c3d4e5f6 -u [email protected]

• Если отказано, они не скажут вам напрямую, почему, вы должны проанализировать ответ JSON.

  LogFileURL: https://osxapps-ssl.itunes.apple.com/itunes-assets/...

• Прочтите JSON и устраните выявленные проблемы. JSON уменьшен, вы можете запустить его через красивое средство форматирования. Если проблем нет, значит ваше приложение нотариально заверено и имеет Ready for distribution.

  
  {
    "logFormatVersion": 1,
    "jobId": "a1b2c3d4e5-a1b2-a1b2-a1b2-a1b2c3d4e5f6",
    "status": "Accepted",
    "statusSummary": "Ready for distribution",
    "statusCode": 0,
    "archiveFilename": "appname.pkg",
    "uploadDate": "2018-10-26T05:41:12Z",
    "sha256": "e2350bda66...",
    "issues" null
  }
  

Сшивание

Наконец, сшивание сборки гарантирует, что пакет будет доверенным, даже если сетевое соединение недоступно.

(apple.com) Вы также должны прикрепить билет к своему программному обеспечению с помощью инструмента степлера, чтобы в будущие дистрибутивы он был включен. Это гарантирует, что Gatekeeper сможет найти билет, даже если сетевое соединение недоступно. Чтобы прикрепить билет к вашему приложению, используйте степлер:

xcrun stapler staple appname.pkg

Время выполнения

Дополнительное решение, предоставляемое @NaderNader, при объединении среды выполнения Java вместе с .app, необходимы дополнительные шаги, чтобы пометить дистрибутив как runtime с помощью флага --option=runtime, где P6DMU6694X - ваш идентификатор подписи:

codesign --force --deep --options=runtime -s "P6DMU6694X" /path/to/My.app

В дополнение к приведенному выше ответу tresf, если ваше приложение находится в песочнице (и, возможно, даже если нет), тогда усиленная среда выполнения завершится с ошибкой при загрузке JVM. Чтобы обойти это, вам нужно будет добавить несколько ключей к своим правам при подписании. Ниже приведены необходимые записи о правах, скопированные из решения TAO ZHOU здесь: https://github.com/TheInfiniteKind/appbundler/issues/39

<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>
<true/>

Вот простой сценарий оболочки, который будет кодировать .so, .dylib и .jnilib в файле jar.

использование: codesign_jar_script.sh filename.jar

jar tf $1 | grep '\.so\|\.dylib\|\.jnilib'  > filelist.txt

IDENTITY="your_signing_identity"

echo $IDENTITY

while read f
do
    jar xf $1 $f
    codesign --force -s "$IDENTITY" -v $f
    jar uf $1 $f
    rm -rf $f
done < filelist.txt