Mac App Store 용 프레임 워크 번들을 어떻게 코딩합니까?

Mac App Store 용 프레임 워크 번들을 어떻게 코딩합니까?

---

최근 제출 후 다음 오류가 발생했습니다.

잘못된 서명-중첩 된 앱 번들 (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

Technote 2206은 다음과 같이 말합니다.

서명 프레임 워크

프레임 워크가 번들이기 때문에 프레임 워크에 직접 서명 할 수 있다는 결론을 내리는 것이 논리적으로 보입니다. 그러나 이것은 사실이 아닙니다. 프레임 워크에 서명 할 때 문제를 방지하려면 전체 프레임 워크가 아닌 특정 버전에 서명해야합니다.

# 이것은 잘못된 방법입니다.

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

# 이것이 올바른 방법입니다.

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

재미를 위해 프레임 워크 번들에 직접 서명을 시도했지만 여전히 거부되었습니다. 그러나 그것은 정확히 문서가하지 말라고 말한 것입니다.

왜 그것이 유효하지 않은지 추측합니까? 나는 과거에 작동했던 내 앱을 코드 서명하는 데 사용하는 것과 동일한 인증서를 사용하고 있습니다.

내 유일한 추측은 기존 plist (프레임 워크의 Info.plists에있는 식별자를 소유해야합니까?) 또는 권한 (제안 사항)과 관련이있을 것입니다.

---

baptr의 답변을 기반으로 모든 프레임 워크 및 기타 바이너리 리소스 / 보조 실행 파일 (현재 지원되는 유형 : 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내 프로젝트 루트의 하위 디렉토리에 사본을 보관 합니다.
   • Mine is called codesign-frameworks.sh.
2. Add a “Run Script” build phase right after your “Copy Embedded Frameworks” build phase.
   • You can call it “Codesign Embedded Frameworks”.
3. Paste ./codesign-frameworks.sh (or whatever you called your script above) into the script editor text field. Use ./Scripts/codesign-frameworks.sh if you store the script in a subdirectory.
4. Build your app. All bundled frameworks will be codesigned.

Should you still get an “Identity: ambiguous (matches: …” error, please comment below. This should not happen anymore.

Updated 2012-11-14: Adding support for frameworks with special characters in their name (this does not include single quotes) to “codesign-frameworks.sh”.

Updated 2013-01-30: Adding support for special characters in all paths (this should include single quotes) to “codesign-frameworks.sh”.

Updated 2013-10-29: Adding experimental dylib support.

Updated 2013-11-28: Adding entitlements support. Improving experimental dylib support.

Updated 2014-06-13: Fixing codesigning issues with frameworks containing (nested) frameworks. This was done by adding -depth option to find, which causes find to do a depth-first traversal. This has become necessary, because of the issue described here. In short: a containing bundle can only be signed if its nested bundles are signed already.

Updated 2014-06-28: Adding experimental bundle support.

Updated 2014-08-22: Improving code and preventing failure to restore IFS.

Updated 2014-09-26: Adding support for login items.

Updated 2014-10-26: Quoting directory checks. This fixes the “line 31/42: too many arguments” errors and the resulting “ code object is not signed at all” error for paths including special characters.

Updated 2014-11-07: Resolving the ambiguous identity error (like “Mac Developer: ambiguous …”) when using automatic identity resolution in Xcode. You don’t have to explicitly set the identity anymore and can just use “Mac Developer”!

Updated 2015-08-07: Improving semantics.

Improvements welcome!

---

Your comment shows you signed the objects within the bundle's version directory. The Technote shows to sign the directory itself.

The following matches the Technote better:

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

---

This is how I fixed it;

• Enter to the build settings of your target
• Fing the line "Other Code Signing Flags"
• Enter --deep value to the release parameter
• Close XCode
• Enter to the derived data folder on your Mac and delete the old derived data (default path is: /Users/YOUR_USER_NAME/Library/Developer/Xcode/DerivedData)
• Open Xcode and build

After the build archive and submit the app again...

---

One thing I don't see mentioned here is that you need to have your Info.plist inside /Resources inside the versioned framework directory. Otherwise you'll get the "bundle format unrecognized, invalid, or unsuitable" error when you try to sign the versioned directory.

I provided a more extended answer here: How to Codesign Growl.framework for Sandboxed Mac App

참고URL : https://stackoverflow.com/questions/7697508/how-do-you-codesign-framework-bundles-for-the-mac-app-store