Tworzenie układów iOS/OSX: czy należy je kodować przed dystrybucją do innych programistów?

Question

Uczę się tworzenia frameworków iOS i OSX. Weźmy iOS na przykład następujące etapy pracy dla mnie do tej pory:

1. xcodebuild ramy za pomocą -sdk iphonesimulator i Buduj działania ramowego
2. xcodebuild użyciu -sdk iPhoneOS i Buduj działania
3. Użyj narzędzia do tworzenia lipo universal binary tak że lipo -info produkuje spodziewanych:

Architectures in the fat file: Foo.framework/Foo are: i386 x86_64 armv7 arm64

pytania są:

1. czytam, że moje ramy mogą być ponownie podpisane przez dewelopera, który używa go: „Kod Zarejestruj Skopiuj”, ale nie rozumiem, jakie są warunki na to znaczy Dodam codesign krok do codesign że powszechny binarny z moją tożsamością podpisu przed dystrybucją do innych deweloperów?

2. jeśli poprzedni jest pozytywny - czy powinienem użyć mojej tożsamości "iPhone Distribution: ..." lub "iPhone Developer: ..." wystarcza (tak, że moja struktura jest częścią jakiegoś projektu iOS przekazuje wszystkie rodzaje sprawdzania poprawności, w szczególności walidacja App Store) ?.

Tło na moją odpowiedź jest „błąd CodeSign: Kod podpisu jest potrzebny do rodzaju produktu«ramowego»w«iOS 8.3»SDK”, które widziałem na kilku ram trzecich i Carthage#235 lub " obiekt kodu nie jest podpisany na wszystkich”(jeden przykład:. emisji zgłosiłem na Realm#1998

Więc chcę mieć pewność, że użytkownicy mojego ram nie napotka żadnych problemów codeSigning kiedy ich używać

PS Ten. Pytanie staje się jeszcze bardziej interesujące, gdy stosuje się je nie do pojedynczego programisty, ale do organizacji będącej ramą sprzedawca.

Answer 1

Otworzyłem nagrodę: "Poszukuję odpowiedzi z wiarygodnych i/lub oficjalnych źródeł." ale nie otrzymałem takich od tego czasu.

Chociaż odpowiedź udzielona przez @jackslash jest poprawna, mówi tylko część historii, więc chcę napisać własną w sposób, który chciałbym zobaczyć w chwili, gdy zadawałem to pytanie.

Aktualność tej odpowiedzi to: lipiec 2015. Najprawdopodobniej sytuacja się zmieni.

Przede wszystkim niech twierdzą, że działania niezbędne do prawidłowego kodu podpisania ram powinny być podzielone na kroków ramowego deweloper wziąć i kroki ramowego konsument musi podjąć.

TLDR;

Dla środowiska OSX: Programista może dystrybuować środowisko OSX bez oznaczania go jako konsumenta, a mimo to zmieni go na nowy.

dla iOS ram: Twórca może swobodnie rozpowszechniać iOS ramy bez codeSigning go jako konsument będzie ponownie codesign ją tak, ale Deweloper jest zmuszony przez Xcode do codesign ich ramy, gdy budować dla urządzenia z systemem iOS.

powodu radaru: "iOS frameworks containing simulator slices can't be submitted to the App Store" Konsumentów iOS ram jest zmuszony do uruchomienia specjalnego skryptu jak „copy_frameworks” lub „strip_frameworks”, który wykorzystuje lipo -remove zdejmować plastrów symulator z iOS ramowej i re-codesigns pozbawionego ramy, ponieważ w tym momencie jego oznaczenie identyfikacyjne, niezależnie od tego, czym było (lub nie było), jest usuwane jako efekt uboczny manipulacji lipo -remove.

Dłuższa odpowiedź następuje.

---

Ta odpowiedź nie jest "czerpaniem z wiarygodnych i/lub oficjalnych źródeł", ale opiera się raczej na szeregu obserwacji empirycznych.

empiryczne obserwacje # 1: konsument nie obchodzi, ponieważ będą one ponownie codesign ramy, które otrzymują od Developer

binarne dystrybucje ramowe znanych projektów open source na Github nie codesigned. Polecenie codesign -d -vvvv podaje: "obiekt kodu w ogóle nie jest podpisany" we wszystkich binarnych frameworkach iOS i OSX, z których korzystałem. Kilka przykładów: ReactiveCocoa i Mantle, Realm, PromiseKit.

Z tej obserwacji wynika jasno, że autorzy tych ram zamierzają je kodować przez Konsumenta, w ich imieniu, tj. Konsument musi użyć flagi "Kod Podpisania na Kopii" w fazie budowania "Osadź frameworki" udostępnionej przez Xcode lub użyj niestandardowego skryptu powłoki, który robi to samo ręcznie: framework codesigns w imieniu klienta.

Nie znalazłem żadnego przykładu odwrotnego: struktura open source, która byłaby dystrybuowana z oznaczeniem identyfikacyjnym w niej, więc w pozostałej części odpowiedzi zakładam, że to powszechnie przyjęte podejście jest poprawne: nie ma potrzebujemy programistycznego środowiska programistycznego do dystrybucji swoich frameworków do innych programistów z oznaczeniami w nim oznaczającymi tożsamość, ponieważ Konsument zrezygnuje z niego ponownie pod numerem.

empiryczne obserwacje # 2, który dotyczy tylko iOS i która jest całkowicie twórcy troska

Podczas gdy konsument nie obchodzi czy ram, które otrzymują od deweloper jest codesigned lub nie, Programista nadal musi codesign ich iOS framework jako część procesu kompilacji, gdy budują go na urządzenie z systemem iOS, ponieważ w przeciwnym razie Xcode nie buduje: CodeSign error: code signing is required for product type 'Framework' in SDK 'iOS 8.1'. Zacytować Justin Spahr-Summers:

OS X frameworks don't need to be codesigned at build... Unfortunately, Xcode does require that iOS frameworks be codesigned at build time.

To całkiem dobrze odpowiedzi na moje pytanie # 2: „iPhone Developer” tożsamość wystarczy nakłonić Xcode tak, że będzie budować iOS ramy urządzenia. This comment on Carthage#339 mówi to samo.

empiryczne obserwacje # 3: narzędzie lipo

Specyficzne zachowanie narzędzia lipo: po nałożeniu ramowej binarnym, to zawsze rekurencyjnie usuwa wszelkie codesign tożsamości z niego: lipo -create/-remove codesigned framework ... -> not codesigned framework.

To może być odpowiedź, dlaczego wszystkie przykłady z obserwacji nr 1 nie są w ogóle kodowane: ich oznaczenia tożsamości są usuwane po zastosowaniu lipo, ale ponieważ zgodnie z obserwacją nr 1 konsument nie dba o to, że wszystko jest w porządku.

Ta obserwacja jest szczególnie istotna dla następnej obserwacji nr 4 dotyczącej AppStore.

empiryczne obserwacje # 4: iOS ramy zawierające plasterki symulatora nie można składać do App Store

ta jest szeroko dyskutowana w: Realm#1163 i Carthage#188 i radar jest otwarty: rdar://19209161.

Jest to całkowicie niepokój Konsumenta: w przypadku uniwersalnej platformy iOS, którą Konsument zawiera w swojej aplikacji, podczas tworzenia aplikacji, musi uruchomić specjalny skrypt (niestandardową fazę uruchamiania skryptu), która usuwa wycinek symulatora z pliku binarnego tej struktury, aby aplikacja mogła przekazać weryfikację AppStore.

Dobry przykład dla frameworków binarnych, które znalazłem w obszarze Realm: strip-frameworks.sh.

Wykorzystuje lipo usunąć wszystkie plasterki architektur innych niż ${VALID_ARCHS} a następnie ponownie codesigns go Konsumenta tożsamości - to gdzie obserwacja # 3 rzuty w: ram ma być ponownie codesigned powodu manipulacji Lipo na nim .

Kartagraf ma skrypt CopyFrameworks.swift, który robi to samo ze wszystkimi ramami zawartymi przez konsumenta: usuwa fragmenty symulatora i ramy re-kodów w imieniu konsumenta.

Istnieje również dobry artykuł: Stripping Unwanted Architectures From Dynamic Libraries In Xcode.

---

Teraz przegląd kroków wymaganych do stworzenia systemu operacyjnego iOS i OSX zarówno z perspektywy programisty, jak i konsumenta. Najpierw łatwiejsze jeden:

OSX

Developer:

1. Buduje OSX ramowa
2. Daje to Consumer

No codeSigning działania są wymagane od programisty.

konsumentów:

1. Odbiera OSX ramy od Developer
2. Kopie ramy do: ram/i codesigns go automatycznie na swoim, konsumenta, w imieniu jako część „Kodu Wpisz na kopię” procesu.

iOS

Developer:

1. Buduje iOS ramy urządzenia. Kodowanie jest wymagane przez Xcode, wystarczy tożsamość "programisty iPhone'a".
2. Tworzy framework iOS dla symulatora.
3. Używa lipo, który tworzy uniwersalną strukturę iOS z poprzednich dwóch. W tym momencie zgubiona zostaje sygnująca tożsamość 1 kroku: uniwersalny binarny framework "w ogóle nie jest podpisany", ale to dobrze, ponieważ "Konsument nie dba".
4. Daje to Consumer

konsumentów:

1. Odbiera iOS ramy od Developer
2. Kopie ramy Frameworks/katalogu (ten etap może być zbędne w zależności od tego, co skrypt w kroku 3.)
3. Używa specjalnego skryptu jako części procesu kompilacji: ten skrypt usuwa fragmenty symulatora poza ramy systemu iOS, a następnie ponownie je koduje na swoich klientach, w imieniu.

Answer 2

Odczytanie powiązanego wątku repozytorium Kartaginy wydaje się stosunkowo proste. Jeśli rozpowszechniasz binarny framework, musisz go podpisać, a jeśli rozprowadzasz źródło za pomocą kartagonu lub strąków kakao, to nie za pomocą tych narzędzi zadbaj o to za pomocą różnych metod.

Powodem, dla którego musisz podpisać kod podczas dystrybucji struktury binarnej, jest to, że Xcode nie tworzy binarnego kodu bez podpisywania kodu. Jeśli próba nie kodować podpisania ramy binarny można dostać ten błąd:

CodeSign error: code signing is required for product type 'Framework' in SDK 'iOS 8.1' 

To nie ma znaczenia, który tożsamość kodować podpisać z ramy (iPhone Developer lub iPhone Distribution), ponieważ, jak wskazują obecnie, struktura zostanie ponownie zaszyfrowana z ustawieniem "podpisania kodu na kopii". Oznacza to, że Twoja struktura zostanie ponownie zaszyfrowana przez odpowiedni certyfikat z profilu programisty konsumenta szkieletowego, gdy twój framework zostanie skopiowany do jego aplikacji. Oznacza to, że nie będzie problemów ze sklepem App Store, ponieważ będzie widział tylko końcowy podpis kodu od konsumenta.

Pod koniec dnia możesz równie dobrze podpisać swój plik .framework, ponieważ nie chcesz utrzymywać egzotycznego procesu kompilacji, a ponieważ Xcode wyprowadza tylko podpisane frameworki, nie powinieneś się ruszać daleko od domyślnych.Tak naprawdę nie ma to znaczenia, ponieważ końcowy konsument będzie go ponownie podpisywać.