Как вы кодируете фреймворки для Mac App Store - PullRequest
80 голосов
/ 08 октября 2011

После недавней отправки я получил следующую ошибку:

Неверная подпись - вложенный пакет приложений (FooBar.app/Contents/Frameworks/GData.framework) не подписан, подпись недействительна или не подписана сертификатом Apple. Подробнее см. В Руководстве по подписанию кода и изолированной программной среде приложения.

Неверная подпись - вложенный пакет приложений (FooBar.app/Contents/Frameworks/Growl.framework) не подписан, подпись недействительна или не подписана сертификатом Apple. Подробнее см. В Руководстве по подписыванию кода и изолированной программной среде приложения.

Неверная подпись - вложенный пакет приложений libcurl (FooBar.app/Contents/Frameworks/libcurl.framework) не подписан, подпись недействительна или не подписана сертификатом Apple. Подробнее см. В Руководстве по подписыванию кода и изолированной программной среде приложения.

Итак, я подписал все пакеты фреймворков на Technote 2206 :

codesign -f -v -s "3rd Party Mac Developer Application: Name" ./libcurl.framework/Versions/A/libcurl
codesign -f -v -s "3rd Party Mac Developer Application: Name" ./libcurl.framework/Versions/A/libssh2.1.dylib
codesign -f -v -s "3rd Party Mac Developer Application: Name" ./Growl.framework/Versions/A/Growl
codesign -f -v -s "3rd Party Mac Developer Application: Name" ./GData.framework/Versions/A/GData

Технический комментарий 2206 говорит:

Подписание Рамок

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

# Это неправильный путь:

кодовый знак -s моя-подпись-идентификатор ../FooBarBaz.framework

# Это правильный путь:

кодовый знак -s-моя-подпись-идентификатор ../FooBarBaz.framework/Versions/A

И когда я пытаюсь проверить результаты, это выглядит хорошо для меня:

% codesign -vvv FooBar.app/Contents/Frameworks/libcurl.framework
FooBar.app/Contents/Frameworks/libcurl.framework: valid on disk
FooBar.app/Contents/Frameworks/libcurl.framework: satisfies its Designated Requirement
% codesign -vvv FooBar.app/Contents/Frameworks/Growl.framework
FooBar.app/Contents/Frameworks/Growl.framework: valid on disk
FooBar.app/Contents/Frameworks/Growl.framework: satisfies its Designated Requirement

Ради интереса я попытался подписать пакет фреймворков напрямую, и он все еще был отклонен. Но это именно то, что в документации сказано не делать.

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

Моим единственным предположением было бы что-то делать с существующими списками (нужно ли мне иметь идентификаторы в Info.plists фреймворка?) Или разрешениями - какие-либо предложения?

Ответы [ 4 ]

41 голосов
/ 01 июля 2012

Основываясь на ответе baptr, я разработал этот сценарий оболочки, который кодирует все мои фреймворки и другие двоичные ресурсы / вспомогательные исполняемые файлы (в настоящее время поддерживаются типы: dylib, bundle и элементы входа в систему):

#!/bin/sh

# WARNING: You may have to run Clean in Xcode after changing CODE_SIGN_IDENTITY! 

# Verify that $CODE_SIGN_IDENTITY is set
if [ -z "${CODE_SIGN_IDENTITY}" ] ; then
    echo "CODE_SIGN_IDENTITY needs to be set for framework code-signing!"

    if [ "${CONFIGURATION}" = "Release" ] ; then
        exit 1
    else
        # Code-signing is optional for non-release builds.
        exit 0
    fi
fi

if [ -z "${CODE_SIGN_ENTITLEMENTS}" ] ; then
    echo "CODE_SIGN_ENTITLEMENTS needs to be set for framework code-signing!"

    if [ "${CONFIGURATION}" = "Release" ] ; then
        exit 1
    else
        # Code-signing is optional for non-release builds.
        exit 0
    fi
fi

ITEMS=""

FRAMEWORKS_DIR="${TARGET_BUILD_DIR}/${FRAMEWORKS_FOLDER_PATH}"
if [ -d "$FRAMEWORKS_DIR" ] ; then
    FRAMEWORKS=$(find "${FRAMEWORKS_DIR}" -depth -type d -name "*.framework" -or -name "*.dylib" -or -name "*.bundle" | sed -e "s/\(.*framework\)/\1\/Versions\/A\//")
    RESULT=$?
    if [[ $RESULT != 0 ]] ; then
        exit 1
    fi

    ITEMS="${FRAMEWORKS}"
fi

LOGINITEMS_DIR="${TARGET_BUILD_DIR}/${CONTENTS_FOLDER_PATH}/Library/LoginItems/"
if [ -d "$LOGINITEMS_DIR" ] ; then
    LOGINITEMS=$(find "${LOGINITEMS_DIR}" -depth -type d -name "*.app")
    RESULT=$?
    if [[ $RESULT != 0 ]] ; then
        exit 1
    fi

    ITEMS="${ITEMS}"$'\n'"${LOGINITEMS}"
fi

# Prefer the expanded name, if available.
CODE_SIGN_IDENTITY_FOR_ITEMS="${EXPANDED_CODE_SIGN_IDENTITY_NAME}"
if [ "${CODE_SIGN_IDENTITY_FOR_ITEMS}" = "" ] ; then
    # Fall back to old behavior.
    CODE_SIGN_IDENTITY_FOR_ITEMS="${CODE_SIGN_IDENTITY}"
fi

echo "Identity:"
echo "${CODE_SIGN_IDENTITY_FOR_ITEMS}"

echo "Entitlements:"
echo "${CODE_SIGN_ENTITLEMENTS}"

echo "Found:"
echo "${ITEMS}"

# Change the Internal Field Separator (IFS) so that spaces in paths will not cause problems below.
SAVED_IFS=$IFS
IFS=$(echo -en "\n\b")

# Loop through all items.
for ITEM in $ITEMS;
do
    echo "Signing '${ITEM}'"
    codesign --force --verbose --sign "${CODE_SIGN_IDENTITY_FOR_ITEMS}" --entitlements "${CODE_SIGN_ENTITLEMENTS}" "${ITEM}"
    RESULT=$?
    if [[ $RESULT != 0 ]] ; then
        echo "Failed to sign '${ITEM}'."
        IFS=$SAVED_IFS
        exit 1
    fi
done

# Restore $IFS.
IFS=$SAVED_IFS
  1. Сохраните его в файл в вашем проекте. Я храню свою копию в подкаталоге Scripts в корне моего проекта.
    • Шахта называется codesign-frameworks.sh.
  2. Добавьте фазу сборки «Run Script» сразу после фазы сборки «Copy Embedded Frameworks».
    • Вы можете назвать это «Codesign Embedded Frameworks».
  3. Вставьте ./codesign-frameworks.sh (или как вы назвали свой скрипт выше) в текстовое поле редактора скриптов. Используйте ./Scripts/codesign-frameworks.sh, если вы храните скрипт в подкаталоге.
  4. Создайте свое приложение. Все связанные рамки будут иметь кодовую подпись.

Если вы по-прежнему получаете ошибку « Identity : неоднозначная (соответствует:…», пожалуйста, прокомментируйте ниже. Это больше не должно происходить.

Обновлено 2012-11-14: добавлена ​​поддержка платформ со специальными символами в названии (не включая одинарные кавычки) в «codesign-frameworks.sh».

Обновлено 2013-01-30: добавлена ​​поддержка специальных символов во всех путях (включая одинарные кавычки) в «codesign-frameworks.sh».

Обновлено 2013-10-29: добавлена ​​экспериментальная поддержка dylib.

Обновлено 2013-11-28: добавлена ​​поддержка прав. Улучшение экспериментальной поддержки dylib.

Обновлено 2014-06-13: устранение проблем с кодированием при помощи каркасов, содержащих (вложенные) каркасы. Это было сделано путем добавления опции -depth к find, которая заставляет find выполнять обход в глубину. Это стало необходимым из-за проблемы, описанной здесь . Вкратце: содержащий пакет может быть подписан, только если его вложенные пакеты уже подписаны.

Обновлено 2014-06-28: добавлена ​​экспериментальная поддержка комплектов.

Обновлено 2014-08-22: улучшение кода и предотвращение сбоя восстановления IFS.

Обновлено 2014-09-26: добавлена ​​поддержка элементов входа в систему.

Обновлено 2014-10-26: цитирование проверок каталогов. Это исправляет ошибки «строка 31/42: слишком много аргументов» и результирующая ошибка «объект кода вообще не подписан» для путей, включающих специальные символы.

Обновлено 2014-11-07: устранение неоднозначной ошибки идентификации (например, «Mac Developer: неоднозначная…») при использовании автоматического разрешения идентификации в XCode. Вам больше не нужно явно устанавливать личность и вы можете просто использовать «Mac Developer»!

Обновлено 2015-08-07: Улучшение семантики.

Улучшения приветствуются!

10 голосов
/ 02 декабря 2011

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

Следующее соответствует Technote лучше:

codesign -f -v -s "3rd Party Mac Developer Application: Name" ./libcurl.framework/Versions/A
codesign -f -v -s "3rd Party Mac Developer Application: Name" ./Growl.framework/Versions/A
codesign -f -v -s "3rd Party Mac Developer Application: Name" ./GData.framework/Versions/A
3 голосов
/ 11 сентября 2015

Вот как я это исправил;

  • Войдите в настройки сборки вашей цели
  • Введите строку "Другие флаги подписи кода"
  • Введите - глубокое значение параметра выпуска
  • Закрыть XCode
  • Войдите в папку производных данных на вашем Mac и удалите старые производные данные (путь по умолчанию: / Users /YOUR_USER_NAME / Библиотека / Разработчик / Xcode / DerivedData)
  • Откройте Xcode и выполните сборку

После создания архива и снова отправьте приложение ...

0 голосов
/ 09 августа 2013

Одна вещь, о которой я не упомянул, это то, что вам нужно, чтобы ваш Info.plist находился внутри / Resources внутри директории версионного фреймворка. В противном случае вы получите сообщение об ошибке «формат пакета не распознан, недопустим или непригоден» при попытке подписать версионный каталог.

Я предоставил более подробный ответ: Как разработать Growl.framework для приложения Mac с песочницей

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...