Подписание приложения OS X в Windows (без кода)

У меня есть приложение для Windows, которое может работать на OS X под Wine. Для удобства я хочу упаковать приложение как приложение OS X (ZIP-архив папки xxx.app на основе WineBottler).

Обратите внимание, что основной исполняемый файл приложения (как определено тегом CFBundleExecutable в Info.plist) является сценарием оболочки, а не двоичным файлом.

Я хочу подписать приложение для прохождения через OS X Gatekeeper. Поскольку мой полный процесс сборки выполняется в Windows (и поскольку у меня вообще нет Mac), мне нужно подписать его в Windows.

Я уже обнаружил, что при подписании приложения создается папка _CodeSignature с четырьмя файлами:

CodeDirectory
CodeRequirements
CodeResources
CodeSignature

Я не нашел никакой спецификации, описывающей содержимое этих файлов.

Экспериментальным путем я обнаружил, что CodeResources — это файл XML с хэшами SHA-1 всех файлов в приложении. Я могу это сгенерировать.

Содержимое бинарного файла CodeRequirements похоже исправлено. Кажется, это не меняется с содержимым приложения. Подтверждение приветствуется. Чем полезен этот файл?

Насчет бинарных файлов CodeDirectory и CodeSignature понятия не имею.

Оба файла меняются вместе с содержимым приложения. Кажется, что любое изменение файла приложения (включая обычный текстовый файл лицензии) влияет на них.

CodeSignature явно содержит подпись. Я вижу в файле текстовую информацию о сертификате подписи кода. Есть ли инструмент, который может создать файл? Поскольку это подпись, она должна быть довольно стандартной. Хотя могут быть некоторые дополнительные двоичные метаданные, которые могут затруднить генерацию. Кто-нибудь знает, что он конкретно подписывает? Я могу представить, что он подписывает только файл CodeResources, поскольку он описывает все остальные файлы в приложении. Или он рекурсивно подписывает все файлы в приложении?

Нативные приложения OS X имеют только CodeResources. Так что на самом деле в _CodeSignature нет подписи. Я полагаю, это потому, что они встроили подпись в основной исполняемый файл. Обратите внимание, что мой двоичный файл [Windows] (хотя на него напрямую не ссылается Info.plist, как упоминалось выше) имеет кодовую подпись с использованием Windows signtool.exe. По-видимому, OS X распознает подпись даже без ссылки, поскольку вывод codesign -d -vvv xxx.app включает информацию о сертификате:

Executable=/Applications/WinSCP.app/Contents/MacOS/startwine
Identifier=WinSCP
Format=bundle with generic
CodeDirectory v=20100 size=135 flags=0x0(none) hashes=1+3 location=embedded
Hash type=sha1 size=20
CDHash=a1ef4f04b2c1b4b793788ce3ab9d7881528f3d95
Signature size=4867
Authority=Martin Prikryl
Authority=VeriSign Class 3 Code Signing 2010 CA
Authority=VeriSign Class 3 Public Primary Certification Authority - G5
Signed Time=23.4.2014 23:51:18
Info.plist entries=14
Sealed Resources version=2 rules=12 files=846
Internal requirements count=2 size=136

Смущает то, что это вообще не упоминает двоичное имя. Во всяком случае, это не делает Гейткипера счастливым. Обратите внимание, что приведенный выше тест выполняется для приложения, которое уже включает файл CodeResources (вероятно, это то, на что ссылается Sealed Resources version, поскольку счетчики rules и files совпадают с содержимым файла).


macos xcode code-signing code-signing-certificate codesign
person Martin Prikryl    schedule 30.04.2014    source источник
comment
Бинарный файл в формате Mach-O?   -  person trojanfoe    schedule 30.04.2014
comment
Нет, это бинарный файл Windows.   -  person Martin Prikryl    schedule 30.04.2014
comment
Не лучше ли использовать кроссплатформенное фреймворк, такое как Qt, и создавать отдельные двоичные файлы для Windows и Mac? Хотя вы могли бы заставить это работать, UX, как я полагаю, будет довольно плохим.   -  person trojanfoe    schedule 30.04.2014
comment
Ну, это не совсем относится к вопросу, но чтобы ответить вам: я не стремлюсь к кросс-платформенному решению. Я ориентируюсь на Windows. Но поскольку есть немало пользователей, которые используют (или хотят использовать) приложение на OS X, я хочу облегчить им жизнь. Упаковка приложения как приложения Wine — это усилия, которые я готов приложить к этому. Повторная реализация приложения в Qt — это нечто большее.   -  person Martin Prikryl    schedule 30.04.2014
comment
Что вообще делает приложение? Большинство винных приложений будут очень неуместными и странными в OS X. Qt также. Дело не во внешности. Речь идет об условностях ОС и ожиданиях пользователей.   -  person uchuugaka    schedule 30.04.2014
comment
Читали ли вы руководство Apple по подписи кода ( developer.apple. com/library/mac/documentation/security/ )? Он отвечает, по крайней мере, на некоторые ваши вопросы.   -  person danielv    schedule 08.05.2014
comment
@danielv Спасибо за ссылку. Я действительно видел это раньше, но теперь прочитал его более внимательно еще раз. Это подтвердило мое предположение, что CodeRequirements не является частью подписи как таковой и что я должен смотреть в основном на CodeDirectory и CodeSignature. К сожалению, нет описания их строения.   -  person Martin Prikryl    schedule 09.05.2014
comment
Кстати, исходный код утилиты codesign и библиотеки кодирования открыт и доступен: opensource.apple.com/source/security_systemkeychain/ - opensource.apple.com /source/libsecurity_codesigning . Его пробовали раньше, но я не думаю, что он когда-либо компилировался на платформах, отличных от Mac. Но вы можете найти там полезную информацию, если будете просматривать исходный код.   -  person danielv    schedule 09.05.2014
comment
Я не уверен, что вообще возможно подписать приложение, в котором сценарий оболочки является основным исполняемым файлом. Для подписи кода требуется, чтобы двоичный файл был исполняемым файлом MachO.   -  person    schedule 14.05.2014
comment
@duskwuff Это неправда. Просто попробуйте. codesign может подписать практически что угодно. Если нет исполняемого файла MachO, он сохраняет подпись в папке _CodeSignature, а не в исполняемом файле.   -  person Martin Prikryl    schedule 14.05.2014
comment
@danielv Спасибо за ссылки. Глядя на это. Вернусь с моими выводами.   -  person Martin Prikryl    schedule 14.05.2014
comment
@MartinPrikryl: Верно, но я не думаю, что _CodeSignature достаточно для основного исполняемого файла, поскольку он содержит только хэши, а не подпись (т. Е. Из доверенного сертификата).   -  person    schedule 14.05.2014
comment
Благодаря исходному коду, указанному @danielv, я обнаружил, что CodeDirectory содержит хэши всех файлов в комплекте, а CodeSignature является подписью [с использованием указанного доверенного сертификата] CodeDirectory. Таким образом, подпись фактически подписывает каждый отдельный файл пакета.   -  person Martin Prikryl    schedule 14.05.2014
comment
Рассматривали ли вы виртуальную машину под управлением Mac OS?   -  person JWWalker    schedule 26.08.2017
comment
Проверьте isign, это реализация кода на Python.   -  person Xlsx    schedule 18.07.2018

Ответы (2)


arrow_upward
9
arrow_downward

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

Мы обнаружили, что когда codesign не находит двоичный файл MachO, он возвращается к "независимой от архитектуры" подписи, реализованной в SecCodeSigner::Signer::signArchitectureAgnostic.

Ключевые шаги там:

  • CodeDirectory генерация файлов. Каталог включает в себя несколько хэшей SHA-1 различных частей пакета в дополнение к заголовку файла (включая версию каталога).

  • CodeSignature генерация файлов. Подпись подписывает CodeDirectory файл, используя формат Cryptographic Message Syntax (CMS). Подпись можно проверить на любой платформе с помощью OpenSSL:

    openssl cms -verify -in CodeSignature -inform DER
    -content CodeDirectory -noverify -out CodeDirectory.verified

    Обратите внимание, что -noverify необходимо, чтобы пропустить проверку сертификата, поскольку OpenSSL, похоже, не поддерживает назначение сертификатов «подписание кода».

    OpenSSL должен иметь возможность создавать подпись CMS с помощью следующей команды:

    openssl cms -sign -in CodeDirectory -out CodeSignature 
    -signer certificate.pem -outform DER

    Но такая подпись не принимается OS X.

Дальше мы не продвинулись.

person Petr    schedule 15.05.2014
comment
Привет, просто интересно, добились ли вы большего прогресса в этой области... Я пытаюсь создать средство проверки подписи для macho-файла на сервере Linux с помощью openssl.. проверить цепочку подписи CMS - это одно, но я изо всех сил пытаюсь найти как проверить хэш содержимого файла (какие части мачо-файла относятся к каким хэшам в CodeDirectory. возможно, вы знаете, как их вычислить? спасибо! - person Zohar81; 28.11.2018

arrow_upward
3
arrow_downward

Строго не подписываться на Windows, но рассматривали ли вы удаленный рабочий стол в Mac друзей или аренду Mac в облаке? http://www.macincloud.com, кажется, имеет довольно разумные планы.

Может спасти много неприятностей. Все, к чему вам действительно нужен доступ, — это инструмент кодирования и терминал.

Изменить: вам по-прежнему потребуется учетная запись разработчика Apple для подписи приложения — Gatekeeper разрешает подписи только из сертификатов идентификатора разработчика, выданных Apple.

person Dave Satch    schedule 14.05.2014
comment
Спасибо за предложение. Я тоже рассматривал этот подход. Обратите внимание, что вам не нужен сертификат Apple. Мне удалось подписать приложение с помощью codesign даже с сертификатом VeriSign, который у меня есть для подписи приложений Магазина Windows 8. Привратник тоже был доволен. - person Martin Prikryl; 14.05.2014
comment
Кто-нибудь успешно использовал MacinCloud для этой цели? Я только что заметил, что у них есть план предоплаты 1 доллар в час, который, кажется, идеально подходит для нечастых, кратковременных использований. - person mstrap; 15.09.2016