Po ostatnim zgłoszeniu otrzymałem następujący błąd:
Nieprawidłowy podpis - zagnieżdżony pakiet aplikacji (FooBar.app/Contents/Frameworks/GData.framework) nie jest podpisany, podpis jest nieprawidłowy lub nie jest podpisany certyfikatem przesłania Apple. Więcej informacji zawiera Podręcznik podpisywania kodu i piaskownicy aplikacji.
Nieprawidłowy podpis - zagnieżdżony pakiet aplikacji (FooBar.app/Contents/Frameworks/Growl.framework) nie jest podpisany, podpis jest nieprawidłowy lub nie jest podpisany certyfikatem przesłania Apple. Więcej informacji zawiera Podręcznik podpisywania kodu i piaskownicy aplikacji.
Nieprawidłowy podpis - zagnieżdżony pakiet aplikacji libcurl (FooBar.app/Contents/Frameworks/libcurl.framework) nie jest podpisany, podpis jest nieprawidłowy lub nie jest podpisany certyfikatem przesyłania firmy Apple. Więcej informacji zawiera Podręcznik podpisywania kodu i piaskownicy aplikacji.
Więc podpisałem wszystkie paczki frameworka zgodnie z 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 mówi:
Struktury podpisywania
Biorąc pod uwagę, że frameworki są pakietami, logiczne byłoby stwierdzenie, że można bezpośrednio podpisać strukturę. Jednak tak nie jest. Aby uniknąć problemów podczas podpisywania frameworków, upewnij się, że podpisujesz konkretną wersję, a nie cały framework:
# To jest zły sposób:
codeign -s my-signing-identity ../FooBarBaz.framework
# To jest właściwy sposób:
codeign -s my-signing-identity ../FooBarBaz.framework/Versions/A
A kiedy próbuję zweryfikować wyniki, wygląda to dobrze:
% 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
Dla zabawy próbowałem bezpośrednio podpisać pakiet frameworka i nadal został odrzucony. Ale to jest dokładnie to, czego dokumentacja mówi, że nie należy robić.
Jakieś przypuszczenia, dlaczego miałoby to zostać uznane za nieważne? Używam tego samego certyfikatu, którego używam do kodowania podpisywania mojej aplikacji - tego, który działał w przeszłości.
Moje jedyne przypuszczenie to coś związanego z istniejącymi plistami (czy muszę posiadać identyfikatory w Info.plists frameworka?) Lub uprawnieniami - jakieś sugestie?
Odpowiedzi:
Opierając się na odpowiedzi baptr, opracowałem ten skrypt powłoki, który koduje wszystkie moje frameworki i inne zasoby binarne / pomocnicze pliki wykonywalne (obecnie obsługiwane typy: dylib, bundle i elementy logowania):
#!/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
Scripts
podkatalogu w katalogu głównym mojego projektu.codesign-frameworks.sh
../codesign-frameworks.sh
(lub jakkolwiek nazwałeś swój skrypt powyżej) do pola tekstowego edytora skryptów. Użyj,./Scripts/codesign-frameworks.sh
jeśli przechowujesz skrypt w podkatalogu.Jeśli nadal otrzymujesz błąd „ Tożsamość : niejednoznaczne (pasuje:…”), skomentuj poniżej. To nie powinno już się zdarzać.
Zaktualizowano 14.11.2012: Dodanie obsługi frameworków ze znakami specjalnymi w nazwie (nie obejmuje to apostrofów) do „codign-frameworks.sh”.
Zaktualizowano 30.01.2013: Dodanie obsługi znaków specjalnych we wszystkich ścieżkach (powinno to obejmować apostrofy) do „codign-frameworks.sh”.
Zaktualizowano 29.10.2013: Dodanie eksperymentalnej obsługi dylib.
Zaktualizowano 28.11.2013: Dodawanie obsługi uprawnień. Poprawa obsługi eksperymentalnej dylib.
Zaktualizowano 13.06.2014: Naprawianie problemów z podpisywaniem kodów w frameworkach zawierających (zagnieżdżone) frameworki. Dokonano tego poprzez dodanie
-depth
opcji dofind
, która powodujefind
wykonanie przejścia w głąb. Stało się to konieczne ze względu na opisany tutaj problem . W skrócie: paczka zawierająca może zostać podpisana tylko wtedy, gdy jej paczki zagnieżdżone są już podpisane.Zaktualizowano 28.06.2014: Dodanie obsługi pakietów eksperymentalnych.
Zaktualizowano 22.08.2014: Poprawianie kodu i zapobieganie niepowodzeniom w przywracaniu IFS.
Zaktualizowano 26.09.2014: Dodanie obsługi elementów logowania.
Zaktualizowano 26.10.2014: Cytowanie sprawdzeń katalogu. To naprawia błędy „linia 31/42: zbyt wiele argumentów” i wynikowy błąd „obiekt kodu nie jest w ogóle podpisany” dla ścieżek zawierających znaki specjalne.
Zaktualizowano 07.11.2014: Rozwiązywanie niejednoznacznego błędu tożsamości (np. „Mac Developer: niejednoznaczny…”) podczas korzystania z automatycznego rozpoznawania tożsamości w Xcode. Nie musisz już jawnie ustawiać tożsamości i możesz po prostu użyć „Mac Developer”!
Zaktualizowano 07.08.2015: Poprawa semantyki.
Mile widziane ulepszenia!
źródło
Twój komentarz pokazuje, że podpisałeś obiekty w katalogu wersji pakietu. Technote pokazuje, jak podpisać sam katalog.
Poniższe informacje lepiej pasują do noty technicznej:
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
źródło
Tak to naprawiłem;
Po utworzeniu archiwum i ponownie prześlij aplikację ...
źródło
Jedną rzeczą, o której tutaj nie wspomniałem, jest to, że musisz mieć swój plik Info.plist w / Resources wewnątrz wersjonowanego katalogu frameworka. W przeciwnym razie podczas próby podpisania wersjonowanego katalogu pojawi się błąd „Nierozpoznany, nieprawidłowy lub nieodpowiedni format pakietu”.
Podałem bardziej rozszerzoną odpowiedź tutaj: Jak kodować Growl.framework dla aplikacji Sandboxed Mac
źródło