Как вы кодируете пакеты с интерфейсом для Mac App Store?

Question

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

Invalid Signature - the nested app bundle (FooBar.app/Contents/Frameworks/GData.framework) is not signed, the signature is invalid, or it is not signed with an Apple submission certificate. Refer to the Code Signing and Application Sandboxing Guide for more information.

Invalid Signature - the nested app bundle (FooBar.app/Contents/Frameworks/Growl.framework) is not signed, the signature is invalid, or it is not signed with an Apple submission certificate. Refer to the Code Signing and Application Sandboxing Guide for more information.

Invalid Signature - the nested app bundle libcurl (FooBar.app/Contents/Frameworks/libcurl.framework) is not signed, the signature is invalid, or it is not signed with an Apple submission certificate. Refer to the Code Signing and Application Sandboxing Guide for more information.

Так что я подписал все рамочные пакеты на 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 

Technote 2206 говорит:

Signing Frameworks

Seeing as frameworks are bundles it would seem logical to conclude that you can sign a framework directly. However, this is not the case. To avoid problems when signing frameworks make sure that you sign a specific version as opposed to the whole framework:

# This is the wrong way:

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

# This is the right way:

codesign -s my-signing-identity ../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 

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

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

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

Answer 1

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

Следующая соответствует 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 

Answer 2

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

#!/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. Добавьте фазу сборки «Сценарий запуска» сразу после фазы сборки «Скопируйте встроенные рамки».
   • Вы можете назвать это "Codesign Embedded Frameworks".
3. Вставить в текстовое поле редактора сценариев вставить ./codesign-frameworks.sh (или все, что вы назвали своим скриптом). Используйте ./Scripts/codesign-frameworks.sh, если вы храните сценарий в подкаталоге.
4. Создайте приложение. Все вложенные структуры будут закодированы.

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

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

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

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

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

Обновлено 2014-06-13: Исправление проблем с кодовыми обозначениями с помощью фреймворков, содержащих (вложенные) рамки. Это было сделано путем добавления -depth опции к find, что приводит к тому, что find совершает обход глубины. Это стало необходимым, из-за the issue described here. Короче: содержащий пакет может быть подписан только в том случае, если его вложенные пакеты уже подписаны.

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

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

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

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

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

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

Усовершенствования приветствуются!

Answer 3

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

Я предоставил более расширенный ответ здесь: How to Codesign Growl.framework for Sandboxed Mac App

Answer 4

Это, как я установил его;

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

После сборки архива и отправить приложение снова ...