Доверительное и подписывание кода

Доверие определяется политикой. Политика доверия безопасности определяет, должны ли определенные идентификационные данные кода, которые являются по существу определяемым требованием (DR) для кода, быть приняты для разрешения чего-то произойти в системе, например, доступ к ресурсу или службе, после тестирования на законность. Каждая подсистема OS X имеет свою собственную политику и делает это определение отдельно. Таким образом не имеет никакого смысла спрашивать, доверяет ли подписывание кода определенной подписи. Необходимо спросить на основе подсистемы, и это более значимо, чтобы спросить, доверяет ли определенная подсистема подписи.

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

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

• DTA даже не имеет политики отслеживания. Это просто применяет требование набора к каждой запрашивающей стороне, не будучи должен сохранить любую информацию.

• Родительский контроль показывает, что Вы не должны даже использовать подписывание кода вообще для обработки применимой политики.

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

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

Много частей OS X не заботятся об идентификационных данных подписывающего лица. (Привратник является существенным исключением.) Они заботятся только, подписывается ли программа законно и стабильна. Устойчивость определяется через механизм определяемого требования (DR) и не зависит от природы используемого центра сертификации. Система цепочки для ключей и родительский контроль являются примерами такого использования. Самоподписанные идентификационные данные и самодельные центры сертификации (CA) работают по умолчанию на этот случай.

Другие части OS X ограничивают приемлемые подписи к только нарисованным из центров сертификации, которым доверяют в системе, выполняющей проверку. Для тех проверок действительно имеет значение природа используемого удостоверения личности. Брандмауэр Приложения является одним примером этого использования. Самоподписанные идентификационные данные и самосоздаваемый CA не будут проверены как являющийся допустимым для этой проверки, если системе проверки не сказали доверять им в целях Брандмауэра Приложения.

Следует иметь в виду, что использование идентификационных данных подписания, которым в масштабе всей системы доверяют, автоматически не означает, что это:

• требование для подписи, чтобы быть допустимым.

• попытка быть проигнорированным большинством подсистем.

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

Требования кода

Требование кода является оператором что явно выраженные ограничения на законно приложение со знаком. Проверка подписи кода может принять требование как ввод, который будет тогда использоваться, чтобы проверить, подписывается ли код законно и удовлетворяет ограничения требования. При подписании кода не обычно необходимо интересоваться требованиями кода. Ими будут управлять неявно codesign и XCode. Однако в редких случаях Вы, возможно, должны явно переопределить настройки по умолчанию для достижения определенных эффектов.

Чтобы явно протестировать, удовлетворяет ли программа определенное требование, используйте-R опцию для codesign команда; например:

$ # Make a copy of the md5 tool.

$ cp /sbin/md5 .

$ # The copy still satisfies its DR.

$ codesign -vvvv ./md5

./md5: valid on disk

./md5: satisfies its Designated Requirement

$ # And we can check that it's signed by Apple.

$ codesign -vvvv -R="anchor apple" ./md5

./md5: valid on disk

./md5: satisfies its Designated Requirement

./md5: explicit requirement satisfied

$ # Modify the binary.

$ chmod u+w ./md5

$ dd if=/dev/zero bs=1 count=1 seek=8192 conv=notrunc of=./md5

1+0 records in

1+0 records out

1 bytes transferred in 0.000036 secs (27777 bytes/sec)

$ # The modified program no longer satisfies its DR.

$ codesign -vvvv ./md5

./md5: code or signature modified

$ # But we can resign the modified program with our signature.

$ codesign -s my-signing-identity -f ./md5

./md5: replacing existing signature

$ # And the modified program now satisfies its DR.

$ codesign -vvvv ./md5

./md5: valid on disk

./md5: satisfies its Designated Requirement

$ # But not our supplement requirement.

$ codesign -vvvv -R="anchor apple" ./md5

./md5: valid on disk

./md5: satisfies its Designated Requirement

test-requirement: failed to satisfy code requirement(s)

Язык требования является рядом правил, который может быть объединен в цепочку вместе с помощью логических операторов («и», «или», «не», и круглые скобки для обозначения приоритета) для формирования выражения требования. Ниже текущий список поддерживаемых правил и их использования:

Некоторые важные вещи иметь в виду:

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

• Идентификатор подписания также встраивается в DR и примет значение по умолчанию к CFBundleIdentifier найденный в Info.plist для удобства, если Вы не предоставляетесь явно. Идентификатор не имеет никакого значения, насколько подписывание кода затронуто, кроме как средние значения для создания DRs уникальный.

• Можно передать в отрицательных целых числах как индекс в массив цепочки сертификата, если Вы хотите, чтобы ищущий источник запустился с корневого сертификата, а не листа как источник; значение для листового сертификата и корневого сертификата 0 и-1, соответственно. Расстояние для листового источника (положительное целое число) измеряется абсолютным значением целочисленного значения, переданного в. Принимая во внимание, что, расстояние для корневого источника (отрицательное целое число) измеряется абсолютным значением 1 + целочисленное значение передало в.

• Чтобы управлять или экспериментировать с требованиями, используйте csreq команду.

Кодируйте определяемое требование

Весь код со знаком имеет определяемое требование (DR). Эти состояния требования, с точки зрения разработчика программы, что ограничения программа должны удовлетворить для рассмотрения экземпляра этой программы. Очевидно, каждая программа должна удовлетворить свой собственный DR, например, codesign -vv проверки на это. Более интересно DR программы должна также быть удовлетворена обновлениями, т.е. новыми версиями того кода, и ничем иным. Это - то, как механизм политики подписывания кода OS X распознает обновления и обновления.

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

Видеть то, что имеет DR программа:

$ codesign -d -r- /sbin/md5

Executable=/sbin/md5

# designated => identifier "com.apple.md5" and anchor apple

Ищите строку начиная с «определяемого =>». Если это комментируется (запускается с метки «#»), это неявно сгенерировано. В противном случае это явно.

Используйте-r опцию для команды элемента кода для явного указания DR при подписании; например:

$ codesign -vvvv -s my-signing-identity -r="designated => anchor trusted" ~/Desktop/CodesignTest

/Users/admin/Desktop/CodesignTest: signed Mach-O thin (i386) [CodesignTest]

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

$ codesign -vvvv -s my-signing-identity -r="designated => anchor trusted and \

identifier com.foo.bar" ~/Desktop/CodesignTest

/Users/admin/Desktop/CodesignTest: signed Mach-O thin (i386) [CodesignTest]

Законность сертификата

За исключением установленного в следующем абзаце, механизмы подписывания кода и проверки принимают подписи, сделанные с сертификатами с истекшим сроком. Это означает, что Ваш код со знаком не станет недопустимым, когда истечет Ваш сертификат. В простых приложениях можно продолжать подписываться с сертификатом с истекшим сроком, и OS X будет продолжать принимать это. Подписывание кода отклонит подписи, сделанные с идентификационными данными, отмененными согласно стандартным правилам обработки X.509 (См. RFC 3280 для примера). Инструкции проверки аннулирования должны быть встроены в сертификаты, которые Вы хотите проверенный. Проверка аннулирования является предпочтением в расчете на пользователя, найденным в Доступе Цепочки для ключей. Когда проверка аннулирования сконфигурирована и включена, система может все еще быть неспособна установить состояние аннулирования, если это разъединяется от сети, когда проверка могла бы успешно выполниться вместо сбоя, т.е. Если предпочтения Доступа Цепочки для ключей аннулирования сертификата установлены, поскольку «Лучшая Попытка» вместо «Требует, если Свидетельство Указывает».

Разработчик подписи ID переносит криптографические метки времени по умолчанию. Подписи с криптографическими метками времени проверены против времени подписания и подписей, сделанных с с истекшим сроком (при подписании времени), сертификаты недопустимы. Предыдущее обсуждение все еще применяется к Разработчику подписи ID без безопасных меток времени.

Правила ресурса

Системы перед Индивидуалистами OS X задокументировали функцию подписания (--resource-rules) управлять, какие файлы в пакете должны быть изолированы подписью кода. Эта функция была obsoleted для Индивидуалистов. Подписи кода, сделанные в Индивидуалистах и позже всегда, изолируют все файлы в пакете; нет никакой потребности указывать это явно больше. Это также означает, что установка сборки Пути Правил Ресурса Подписывания кода в XCode больше не должна использоваться и должна быть оставлена незаполненная.

Больше не таким образом возможно исключить части пакета от подписи. Пакеты должны быть обработаны как только для чтения, как только они были подписаны.

Вложенный код

От Индивидуалистов вперед, запись подписей вложила код своей подписью кода, и встройте ту информацию в конверт ресурса (внешней) подписи, рекурсивно. Это означает, что, когда подпись кода создается, весь вложенный код должен уже быть подписан правильно, или попытка подписания перестанет работать.

Это не проблема, если Вы следуете за стандартным потоком сборки XCode, потому что он создаст и подпишет цели наизнанку: создайте самый внутренний код, скопируйте его в следующий внешний пакет, затем подпишите это и т.д. Всегда проверяйте это

Вложенный код ожидается во многих стандартных расположениях в пакете.

Эти места, как ожидают, будут содержать только код. Помещение произвольных файлов данных там заставит их быть отклоненными (так как они без знака).

С другой стороны помещение кода в другие места заставит его быть изолированным как данные (ресурс) файлы. Это заставляет этот код быть изолированным дважды; один раз во вложенном коде, и один раз во внешней подписи. Это тратит впустую и время подписания и проверки и пространство памяти. Кроме того, это может повредить внешнюю подпись приложений, использующих их собственные механизмы обновления для замены вложенного кода. Если этот вложенный код обрабатывается как ресурсы, внешняя подпись не знает, что это вложенное содержание является фактически кодом.

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

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

Python хранилища, Perl, оболочка, и другие файлы сценария и другие немужественные исполнимые программы в Вашем приложении Contents/Resources каталог. В то время как возможно подписать такие исполнимые программы и сохранить их в Contents/MacOS, это не рекомендуется.

Кроме того, может не быть никакого содержания на верхнем уровне пакета. Другими словами, если пакет имеет a Contents или Versions каталог на его верхнем уровне, не может быть никаких других файлов или каталогов рядом с ними. Одно исключение - это рядом Versions, могут быть символьные ссылки к файлам в Versions/Current.

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

Пакеты должны иметь их Info.plist в надлежащем расположении. Для комплектов приложений это находится в Contents. Для платформ это находится в Versions/Current/Resources.

Проверка соответствия привратника

Для тестирования соответствия Привратника необходимо использовать OS X 10.9.5 или позже. Выполните эти шаги:

• Упакуйте свою программу путем, Вы поставляете ее, такой как в образе диска.

• Загрузите его с его веб-сайта, или отправьте его по почте себе или отправьте его себе использование AirDrop или сообщение. Это изолирует загруженную копию. Это необходимо для инициирования проверки Привратника, поскольку Привратник только проверяет изолированный, регистрирует в первый раз, когда они открыты.

  Подсказка: сохраните загруженный .dmg вокруг; это останется изолированным, и можно использовать его снова и снова для тестирования.

• Перетаскивать-установка Ваше приложение и запуск это.

• Наблюдайте результаты.

  Подсказка: не запускайтесь изнутри .dmg.

Какие результаты Вы получали?

• Если нет никакого диалогового окна вообще, шаг был пропущен. Проверьте инструкции и повторите тест.

• Если Вы получаете диалоговое окно ... is from the Internet с Open кнопка, тест успешно выполнился.

• Если Вам говорят, что только приложения от App Store Mac или зарегистрированных разработчиков могут быть установлены, Ваше приложение не является подписанным ID Разработчиком. Используйте Организатора XCode, чтобы экспортировать подписанную копию ID Разработчика Вашего приложения и повторить тест.

• Если Вы получаете жалобу, Ваша подпись слаба или повреждается. Рассмотрите Подпись Кода Версии 2 FAQ.

Эта команда:

$ codesign --verify --deep --verbose=2 Foo.app

имитаторы, что Привратник делает для проверки приложения.

Можно также использовать check-signature инструмент для проверки обоих приложений и пакетов установщика.

Смонтируйте образ диска, затем выполните инструмент как это:

$ cd "/Volumes/Signature Check"

$ ./check-signature /Path/to/Foo.app /Path/to/Bar.pkg

Для каждой цели инструмент представит простое YES ответьте, удовлетворяет ли подпись требования Привратника, или NO если это не делает.

Внимательно прочитайте сообщения об ошибках с особым вниманием к in subcomponent: часть, который, если есть говорит Вам, которые вложили код, дает Вам проблемы.

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

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

Как привратник, spctl только примет Разработчика подписанные ID приложения и приложения, загруженные с App Store Mac по умолчанию. Это отклонит приложения, подписанные с сертификатами разработки или распределения App Store Mac.

Выполненный spctl на Вашем приложении как это:

$ spctl -a -t exec -vv Foo.app

Если подпись Вашего приложения будет принята, это - вывод:

Foo.app: accepted

source=Developer ID

source будет Mac App Store для приложений, загруженных с App Store Mac.

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

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

Отодвигание от пользовательских правил ресурса

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

При использовании пользовательских правил ресурса, потому что процесс установки полагается на изменение пакета, приложение будет отклонено Привратником на первом запуске. Эти модификации не разрешены. Используя пакет установки вместо перетаскивать-установки получит Вас через Привратника.

Для поддержки создания подобных капельке приложений или подобных форм персонализации приемлемо поместить строковое представление UUID (например. 16F2ACA8-AA29-48ED-9ED9-F96F3A230505) в расширенный названный атрибут com.apple.application-instance из каталога верхнего уровня Вашего пакета (например. MyApp.app). Это не будет лишать законной силы подпись кода или влиять на идентификационные данные кода пакета. Можно тогда соединить этот UUID с хранением вне пакета, переносящего необходимые данные конфигурации, такие как NSUserDefaults, файл в Application Support каталог или веб-сервис.

Размещение данных конфигурации непосредственно в расширенные атрибуты не поддерживается.

Изменения, не лишающие законной силы подпись кода

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

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

Удаление файлов от .lproj каталоги внутри Contents/Resources не лишит законной силы подпись кода, но добавляющие или изменяющиеся файлы будут.

Удаление Мужественной части для определенной архитектуры от универсального двоичного файла также не лишит законной силы подпись кода.

Подписание с XCode

XCode выполнит все фазы сборки для цели, прежде чем он подпишет ту цель. Это обычно, что Вы хотите, так как Вы не должны вмешиваться в пакет после того, как он был подписан. Если по некоторым причинам необходимо сделать что-то к цели после подписания, создать отдельную совокупную цель, заставьте его зависеть от исходной цели и поместите пользовательские фазы сборки там.

Удостоверьтесь, что Ваши целевые зависимости установлены правильно, таким образом, цели создаются и вошли в систему правильный порядок. Подтвердите, что раздел Identity области General каждой цели имеет то же значение для Команды, таким образом, каждая цель подписывается с теми же идентификационными данными.

Используя Инструмент элемента кода - глубокая Опция Правильно

При заверении подписей добавить --deep выполнять рекурсивную проверку вложенного кода. Без --deep, проверка будет мелка: это проверит непосредственное вложенное содержание, но не проверит это полностью. Обратите внимание на то, что Привратник всегда выполняет --deep проверка стиля.

Обратите внимание на то, что подписываясь с комбинацией --deep --force насильственно оставит весь код в пакете.

Пакеты установщика

Пакеты установщика стиля пакета являются больше не поддерживающимся устаревшим средством перехода. PackageMaker также больше не поддерживается. Теперь необходимо преобразовать в инструменты использования пакетов установщика плоского файла как productbuild.

Если необходимо сделать краткосрочные модификации к существующему .pkg или .mpkg пакеты для получения их через Привратника затем укажите явные правила ресурса, объявляющие, что все файлы в пакете ресурсы без исключений.

Значение по умолчанию codesign поведение для пакетов установщика стиля пакета создает устаревший формат подписи, больше не передающий Привратника.

Используйте check-signature инструмент для проверки пакетов установщика, как описано ранее.

элемент кода говорит, что моя подпись слаба.

• Ваша изоляция пакета является неполной: это исключает некоторые файлы. Все подписи версии 1 слабы по определению. Но если Вы уходите в отставку, как направлено, результат не должен быть слабым.

• Вы использовали правила ресурса сделать Вашу подпись слабой. Это больше не позволяется.

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

• Это больше не позволяется. Если необходимо изменить пакет, сделайте это перед подписанием. При изменении пакета со знаком необходимо оставить его впоследствии.

Я пишу маркер файла/волшебства получения/лицензии в свой пакет после установки.

• Это больше не позволяется.

• Запишите данные в файлы вне пакета, как описано ранее.

• Используйте расширенный механизм атрибута, описал ранее для указания на пакет на эти данные при необходимости.

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

Я храню данные в своем пакете после того, как я подпишу его.

• Это больше не позволяется. Необходимо будет определить местоположение этих данных в другом месте.

• Если Вы пишете данные, прежде чем Ваше выполнение приложения впервые, Привратник отклонит Ваше приложение, потому что подпись будет недопустима.

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

• OS X APIs, полагающийся на допустимые идентификационные данные, перестанет работать.

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

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

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

• Удостоверьтесь, что Ваши целевые зависимости установлены правильно, таким образом, цели создаются и вошли в систему правильный порядок. Подтвердите, что раздел Identity области General каждой цели имеет то же значение для Команды, таким образом, каждая цель подписывается с теми же идентификационными данными.

Элемент кода 'кода' жалуется на, не код. Это - просто некоторые файлы данных.

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

• Не помещайте файлы данных в участки кода. Переместите их в другое место, такой как Contents/Resources.

Я не могу измениться, где мои файлы данных сохранены, значительно не изменяя мой код.

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

• Тогда фиксируйте свой код и удалите символьные ссылки как можно скорее.

элемент кода говорит, что мой код повреждается, когда я пытаюсь подписать его.

• Подпись Вашего вложенного кода повреждается и должна быть фиксирована, как описано ранее.

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

• Ваша Мужественная исполнимая программа не соответствует современным Мужественным правилам макета.

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

Я записал некоторые данные в Мужественный файл перед подписанием. Это позволяется?

• Нет. Не вмешивайтесь в Мужественные файлы, за пределами использования инструментов сборки OS X и потоков операций XCode.

Я встраиваю свои данные в Мужественный файл.

• Используйте -sectcreate опция компоновщика для этого.

элемент кода говорит, что я 'распечатал содержание' где-нибудь.

• Не помещайте файлы или каталоги в главный каталог пакета платформы или приложения

• Все содержание должно быть внутри Contents или Версии соответственно, как описано ранее.

элемент кода говорит, что мой формат пакета неоднозначен.

• codesign думает, что Ваш пакет немного походит на приложение и немного как платформа.

• Возможно, у Вас есть оба Contents и Versions каталоги или файлы в главном каталоге, соответствующие зарезервированные названия для каталогов в пакете.

• Возможно, существует Info.plist в нечетном месте.

• Короче говоря, поместите все в корректные места.

элемент кода говорит, что встроенная платформа является неправильной.

• Проверьте платформу на содержание верхнего уровня, и на надлежащее размещение и содержание Info.plist.

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

• Удостоверьтесь все символьные ссылки в вершине .framework каталог является фактически символьными ссылками и указывает на соответствующий каталог внутри Versions/Current.

Подписание изменяет исполнимую программу

Подписание программы изменит свой основной исполняемый файл. Существуют некоторые ситуации, где это вызовет Вас проблема:

• Если Ваша программа имеет режим самопроверки, обнаруживающий изменение, Ваш код может отказаться работать.

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

Очевидное решение этих проблем не состоит в том, чтобы влезть в Вашу программу со знаком после того, как Вы подписали его с codesign. Если Вы измените исполнимую программу или свяжетесь всегда тогда, то механизм проверки подписывания кода будет, очевидно, брать на том изменении и действовать соответственно с политикой набора. При установке программы, чтобы сделать самопроверку целостности тогда, возможно, что ожидание того, что составляет «программу», вероятно, изменится вследствие подписывания кода. Более в частности, ли Вы проверяете все содержание Мужественного файла или просто агрегации определенных частей файла, очень вероятно, что подписывание кода повредит то, что Вы полагаете, что проверка целостности. Например:

$ # Let's see what the Mach-O file looks like pre-signing:

$ otool -l ~/Desktop/CodesignTest

CodesignTest:

Load command 0

      cmd LC_SEGMENT

  cmdsize 56

  segname __PAGEZERO

   vmaddr 0x00000000

   vmsize 0x00001000

  fileoff 0

 filesize 0

  maxprot 0x00000000

 initprot 0x00000000

   nsects 0

    flags 0x0

[...]

Load command 11

          cmd LC_LOAD_DYLIB

      cmdsize 52

         name /usr/lib/libSystem.B.dylib (offset 24)

   time stamp 2 Wed Dec 31 16:00:02 1969

      current version 111.0.0

compatibility version 1.0.0

$ # Now let's see what it looks like after signing:

$ codesign -vvvv -s my-signing-identity ~/Desktop/CodesignTest

CodesignTest: signed Mach-O thin (i386) [CodesignTest]

$ otool -l CodesignTest

CodesignTest:

Load command 0

      cmd LC_SEGMENT

  cmdsize 56

  segname __PAGEZERO

   vmaddr 0x00000000

   vmsize 0x00001000

  fileoff 0

 filesize 0

  maxprot 0x00000000

 initprot 0x00000000

   nsects 0

    flags 0x0

[...]

Load command 11

          cmd LC_LOAD_DYLIB

      cmdsize 52

         name /usr/lib/libSystem.B.dylib (offset 24)

   time stamp 2 Wed Dec 31 16:00:02 1969

      current version 111.0.0

compatibility version 1.0.0

Load command 12

      cmd LC_CODE_SIGNATURE

  cmdsize 16

 dataoff  12816

 datasize 5232

$ # Notice the extra load command LC_CODE_SIGNATURE at number 12!

$ # Let's check it out even further with pagestuff:

$ pagestuff CodesignTest -a

File Page 0 contains Mach-O headers

[...]

File Page 3 contains local of code signature

File Page 4 contains local of code signature

Подписание платформ

Наблюдение как платформы является пакетами, казалось бы логичным прийти к заключению, что можно подписать платформу непосредственно. Большинство платформ содержит единственную версию и может фактически быть подписано непосредственно. Подписание платформы в целом подписывает свою «Текущую» версию по умолчанию.

Мультиимеющим версию платформам обескураживают в целом. Однако, если Вы, оказывается, имеете один, удостоверьтесь, что Вы подписываете каждую определенную версию в противоположность целой платформе:

$ # This is the wrong way to sign a multi-versioned framework:

$ codesign -s my-signing-identity ../FooBarBaz.framework

$ # This is the right way:

$ codesign -s my-signing-identity ../FooBarBaz.framework/Versions/A

$ codesign -s my-signing-identity ../FooBarBaz.framework/Versions/B

Мультиимеющие версию платформы являются «имеющими версию пакеты», и каждая содержавшая версия должна быть подписана и проверена отдельно.

Расширенное ключевое использование

Стандартные сертификаты X.509 (RFC 2459) содержат идентификаторы объектов (OID), формирующий ключевые расширения использования для определения то, для чего и закрытый ключ с открытым ключом может и не может использоваться. Расширенные ключевые использования просто далее совершенствовали ключевые расширения использования. Расширение является или критически важным или некритическим. Если расширение критически важно, чем идентификационные данные должны только использоваться в обозначенной цели (ях).

Сертификаты X.509 и их подписывание кода расширились, ключевое использование, очевидно, требуется для идентификационных данных использоваться для подписывания кода на OS X. Однако подписывание кода расширилось, ключевое использование должно также быть единственным расширенным ключевым использованием для сертификата (это подписывание кода расширилось, использование критически важно), чтобы быть допустимым к подсистеме подписывания кода OS X. Не возможно создать один сертификат, который может использоваться и для подписывания кода и для других целей.

Можно проверить сертификат, чтобы узнать, расширилось ли подписывание кода, ключевой атрибут использования присутствует путем просмотра сертификата в Доступе Цепочки для ключей или при помощи любого другого совместимого синтаксического анализатора сертификата X.509. Дамп всей доступной информации о сертификате может также показать, имеет ли сертификат другие использования, которые заставят его быть недопустимыми идентификационными данными для использования с подписыванием кода на Mac OS X. Например:

$ # Use security and certtool

$ security find-certificate -a -e clarus@apple.com -p > cert.pem

$ certtool d cert.pem

Serial Number : 01

Issuer Name :

   Common Name : Testing Code Signing

   Org : Apple Inc.

   OrgUnit : DTS

   State : CA

   Country : US

   Locality : Cupertino

   Email addrs : clarus@apple.com

Subject Name :

   Common Name : Testing Code Signing

   Org : Apple Inc.

   OrgUnit : DTS

   State : CA

   Country : US

   Locality : Cupertino

   Email addrs : clarus@apple.com

Cert Sig Algorithm : OID : < 06 09 2A 86 48 86 F7 0D 01 01 05 >

   alg params : 05 00

Not Before : 19:27:16 Nov 14, 2007

Not After : 19:27:16 Nov 13, 2008

Pub Key Algorithm : OID : < 06 09 2A 86 48 86 F7 0D 01 01 01 >

   alg params : 05 00

Pub key Bytes : Length 270 bytes : 00 00 00 00 00 00 00 00 ...

CSSM Key :

   Algorithm : RSA

   Key Size : 2048 bits

   Key Use : CSSM_KEYUSE_VERIFY

Signature : 256 bytes : FF FF FF FF FF FF FF FF ...

Other field: : OID : < 06 0C 60 86 48 01 86 F8 4D 02 01 01 01 17 >

Other field: : OID : < 06 0C 60 86 48 01 86 F8 4D 02 01 01 01 16 >

Extension struct : OID : < 06 03 55 1D 0F >

   Critical : TRUE

   usage : DigitalSignature

Extension struct : OID : < 06 03 55 1D 25 >

   Critical : TRUE

   purpose  0 : OID : < 06 08 2B 06 01 05 05 07 03 03 >

Поставка Кода Со знаком

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

Один способ гарантировать сохранение расширенных атрибутов путем собирания кода со знаком в образе диска чтения-записи (DMG) файл прежде, чем подписаться и затем, после подписания, преобразовывая в только для чтения. Вы, вероятно, не должны использовать образ диска до заключительного этапа пакета, таким образом, другой менее властный метод должен был бы использовать ZIP или файлы XIP.

Интерпретация отказов подписывания кода

Если подписание или проверка перестало работать в codesign команда вследствие проблем с вложенным кодом, команда выведет дополнительную строку

 In subcomponent: path

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

Если Организатор XCode производит ошибку подписывания кода во время подписания распределения, проблема может быть с неправильно помещенным кодом или ресурсами и не проблемой с Вашими идентификационными данными подписания.