Як ви створюєте набори фреймворків для Mac App Store?

81

Після нещодавнього подання я отримав таку помилку:

Недійсний підпис - вкладений пакет програм (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 говорить:

Рамки підписання

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

# Це неправильний шлях:

кодовий дизайн-ідентичність мого підписання ../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 фреймворку?) Або правами - будь-які пропозиції?

xcode  app-store-connect  codesign  mac-app-store 
— csexton
джерело
Я також це відкрив раніше, коли подав свій додаток. На щастя, Apple не відхилила його, але зазначила, що нам доведеться підписувати рамки пізніше. Я думаю, що краще розміщувати на сторінці видань коду Google Growl, і дуже скоро люди збираються натрапити на ту ж проблему.
— koo
2
Також натрапила на цю проблему під час надсилання програми з фреймворком Growl. Я здогадуюсь, що вам доведеться змінити ідентифікатор пакета growl.framework на ваш власний, а потім кодувати його.
— Ендрю
Це дивно: я опублікував додаток, що включає два фреймворки (CorePlot та MacRuby), обидва без підпису. Я запускаю команду code code на пакеті додатків лише один раз, і додаток прийнято без будь-яких коментарів щодо фреймворку. Тепер, якщо ви заглянете в пакет програм ( bit.ly/charterapp ), обидва фреймворки, схоже, підписані. Ви намагалися просто підписати весь додаток?
— p4010
@ p4010, я зробив - вони раніше не підписувались. Наприклад, гарчання - це просто прямий пучок, який вони поширюють. Зараз я маю цей додаток у магазині вже деякий час, тож я припускаю, що це пов’язано з новими матеріалами пісочниці. Коли ви подали свою програму?
— csexton
@Andrew, чи вам працювала зміна ідентифікатора набору?
— csexton

Відповіді:

46

На основі відповіді 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. Додайте фазу збірки "Запуск сценарію" відразу після фази збірки "Копіювання вбудованих фреймворків".
    • Ви можете назвати це “Codesign Embedded Frameworks”.
  3. Вставте ./codesign-frameworks.sh(або те, що ви називали сценарієм вище) у текстове поле редактора сценаріїв. Використовуйте./Scripts/codesign-frameworks.sh якщо ви зберігаєте сценарій у підкаталозі.
  4. Створіть свій додаток. Усі пакети фреймворків будуть кодовано підписані.

Якщо ви все одно отримуєте помилку " Ідентичність : неоднозначна (збіги: ...", будь ласка, коментуйте нижче. Це більше не повинно відбуватися.

Оновлено 14.11.2012: Додавання підтримки для фреймворків із спеціальними символами в їх назві (сюди не входять одинарні лапки) до “codesign-frameworks.sh”.

Оновлено 30.01.2013: Додавання підтримки для спеціальних символів у всіх шляхах (сюди повинні входити одинарні лапки) до “codesign-frameworks.sh”.

Оновлено 29.10.2013: Додано експериментальну підтримку Dylib.

Оновлено 28.11.2013: Додавання підтримки прав. Покращення експериментальної підтримки дилібу.

Оновлено 13.06.2014: Виправлення проблем із кодовим дизайном у фреймворках, що містять (вкладені) фреймворки. Це було зроблено шляхом додавання -depthопції до find, що змушує findробити обхід першої глибини. Це стало необхідним через проблему, описану тут . Коротше кажучи: вміщувальний пакет можна підписати лише в тому випадку, якщо його вкладені пакети вже підписані.

Оновлено 28.06.2014: Додано підтримку експериментального набору.

Оновлено 22.08.2014: Покращення коду та запобігання відмові відновлення IFS.

Оновлено 26.09.2014: Додана підтримка елементів входу.

Оновлено 26.10.2014: Котирування перевірок каталогів. Це виправляє помилки "рядок 31/42: занадто багато аргументів" і результуючу помилку "об'єкт коду взагалі не підписаний" для шляхів, що включають спеціальні символи.

Оновлено 07.11.2014: Вирішення неоднозначної помилки ідентичності (наприклад, “Розробник Mac: неоднозначна…”) при використанні автоматичного розпізнавання ідентифікатора в Xcode. Вам більше не потрібно чітко встановлювати ідентичність, а ви можете просто використовувати “Mac Developer”!

Оновлено 07.08.2015: Покращення семантики.

Ласкаво просимо до вдосконалення!

— JanX2
джерело
Дякуємо за це, лише примітка, хоча це не працює, якщо у вашої цілі є пробіл у своєму імені. Я намагався виправити, але не зміг змусити його працювати, тому змінив ціль.
— Крейг
Має працювати зараз, коли в FRAMEWORK_DIR в його назві є пробіли / спеціальні символи.
— JanX2,
Однак мені також потрібно було вимкнути опцію позначки часу, додавши "--timestamp" в кінець команди кодового дизайну.
— Elmer Cat
Цікаво. Ви @Elmer Cat, випадково, робите це у невипущеній версії OS X? Сторінка man описує цю опцію "поведінки за замовчуванням для конкретної системи".
— JanX2
1
Елмер Кіт - я не знаю, яку версію Xcode ви використовуєте, але я працюю на 5.0.1, і це точно НЕ підписує мої фреймворки автоматично. Я виривав волосся, поки не знайшов цей сценарій.
— Брайан
11

Ваш коментар показує, що ви підписали об'єкти в каталозі версій пакета. Technote показує, що підписує сам каталог.

Наступне краще відповідає 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
— баптр
джерело
4

Ось як я це виправив;

  • Увійдіть до налаштувань збірки своєї цілі
  • Знайдіть рядок "Інші прапори для підписання коду"
  • Введіть --deep значення для параметра випуску
  • Закрийте XCode
  • Увійдіть до папки похідних даних на вашому Mac і видаліть старі похідні дані (шлях за замовчуванням: / Users / YOUR_USER_NAME / Library / Developer / Xcode / DerivedData)
  • Відкрийте Xcode і побудуйте

Після побудови архіву та подайте програму ще раз ...

— emreoktem
джерело
3
У світі мрій "- глибоко" буде працювати, як очікувалося, але ми не живемо у світі мрії ...
— Майк
0

Одне, що я не бачу тут згадуваного, - це те, що вам потрібно мати ваш Info.plist всередині / Resources всередині каталогу версій. В іншому випадку ви отримаєте помилку "формат розшарування нерозпізнаний, недійсний або непридатний" при спробі підписати версійний каталог.

Тут я надав більш розширену відповідь: Як програмувати програму Growl.framework для додатків Mac із захищеною середовищем

— Росс Бенчіна
джерело
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.