iOS / OSX 프레임 워크 생성 : 다른 개발자에게 배포하기 전에 코드 서명이 필요합니까?

iOS / OSX 프레임 워크 생성 : 다른 개발자에게 배포하기 전에 코드 서명이 필요합니까?

---

iOS 및 OSX 프레임 워크를 만드는 방법을 배우고 있습니다. 예를 들어 iOS를 살펴보면 지금까지 다음 단계가 저에게 효과적입니다.

1. -sdk iphonesimulator 및 빌드 작업을 사용하는 xcodebuild 프레임 워크
2. -sdk iphoneos 및 빌드 작업을 사용하는 xcodebuild 프레임 워크
3. lipo 도구를 사용 lipo -info하여 예상되는 결과를 생성 하도록 범용 바이너리를 만듭니다 .

fat 파일의 아키텍처 : Foo.framework / Foo : i386 x86_64 armv7 arm64

질문은 다음과 같습니다.

1. 내 프레임 워크를 사용하는 개발자가 "코드 사인 온 복사"에 의해 재 서명 될 수 있다는 것을 읽었습니다.하지만 전제 조건이 무엇인지 이해하지 못합니다. 예 를 들어 이전에 내 서명 ID로 해당 범용 바이너리를 코드 서명하기 위해 코드 서명 단계를 추가해야합니까? 다른 개발자에게 배포 하시겠습니까?

2. 이전이 긍정적 인 경우- "iPhone 배포 : ..."ID 또는 "iPhone 개발자 : ..."를 사용해야하는 경우 충분합니다 (일부 iOS 프로젝트의 일부인 내 프레임 워크가 모든 종류의 유효성 검사, 특히 App Store 유효성 검사를 통과하도록 ) ?.

내 대답에 대한 배경은 "CodeSign 오류 : SDK 'iOS 8.3'의 제품 유형 '프레임 워크'에 대해 코드 서명이 필요합니다."입니다. 여러 타사 프레임 워크 및 Carthage # 235 에서 본 적이 있거나 "코드 개체가 서명되지 않았습니다. at all "(한 가지 예 : Realm # 1998 에서보고 한 문제 .

따라서 내 프레임 워크의 사용자가 사용할 때 코드 서명 문제가 발생하지 않도록하고 싶습니다.

PS이 질문은 단일 개발자가 아니라 프레임 워크 공급 업체 인 조직에 적용될 때 더욱 흥미로워집니다.

---

나는 현상금을 열었습니다 : "신뢰할 수있는 그리고 / 또는 공식적인 출처에서 얻은 답을 찾고 있습니다." 하지만 그 이후로는받지 못했습니다.

@jackslash가 제공 한 답변은 정확하지만 이야기의 일부만 전달하므로이 질문을하는 순간에보고 싶었던 방식으로 직접 작성하고 싶습니다.

이 답변의 실제는 2015 년 7 월입니다. 상황이 바뀔 가능성이 가장 높습니다.

먼저 프레임 워크의 올바른 코드 서명에 필요한 작업 을 프레임 워크의 개발자가 수행 해야하는 단계 와 프레임 워크의 소비자가 수행 해야하는 단계 로 구분해야한다고 주장합시다 .

TLDR;

OSX 프레임 워크의 경우 : 소비자가 어쨌든 다시 공동 설계하므로 개발자는 코드 서명없이 OSX 프레임 워크를 배포 할 수 있습니다.

iOS 프레임 워크의 경우 : 개발자는 코드 서명없이 iOS 프레임 워크를 무료로 배포 할 수 있습니다. 소비자는 어쨌든이를 다시 공동 설계 할 것이기 때문에 개발자는 Xcode가 iOS 장치 용으로 빌드 할 때 프레임 워크를 코드 서명해야합니다.

레이더 때문에 : "시뮬레이터 슬라이스를 포함하는 iOS 프레임 워크는 App Store에 제출할 수 없습니다 . "iOS 프레임 워크 소비자는 iOS 프레임 워크 lipo -remove에서 시뮬레이터 슬라이스를 제거 하는 데 사용 하는 "copy_frameworks"또는 "strip_frameworks"와 같은 특수 스크립트를 실행해야합니다. -codesigns는 프레임 워크를 제거했습니다.이 시점에서 코드 서명 ID가 무엇이든 lipo -remove조작의 부작용으로 제거 되었기 때문입니다 .

더 긴 대답이 이어집니다.

---

이 답변은 "신뢰할 수있는 및 / 또는 공식적인 출처에서 도출"한 것이 아니라 여러 경험적 관찰을 기반으로합니다.

경험적 관찰 # 1 : 소비자는 개발자로부터받은 프레임 워크를 재 설계 할 것이기 때문에 관심이 없습니다.

Github에서 잘 알려진 오픈 소스 프로젝트의 바이너리 프레임 워크 배포는 코드 서명 되지 않습니다 . 명령 codesign -d -vvvv은 내가 탐색하는 데 사용한 모든 바이너리 iOS 및 OSX 프레임 워크에서 "코드 객체가 전혀 서명되지 않았습니다"를 제공합니다. 몇 가지 예 : ReactiveCocoa 및 Mantle , Realm , PromiseKit .

이러한 관찰을 통해 이러한 프레임 워크의 작성자는 소비자를 대신하여 소비자가 코드 서명하도록 의도했음을 알 수 있습니다. 즉, 소비자는 Xcode에서 제공하는 "임베드 프레임 워크"빌드 단계에서 "Code Sign on Copy"플래그를 사용하거나 일부 사용자 지정 셸을 사용해야합니다. 수동으로 동일한 작업을 수행하는 스크립트 : 소비자를 대신하여 프레임 워크를 코드 서명합니다.

그 반대의 예는 하나도 찾지 못했습니다. 코드 서명 ID와 함께 배포되는 오픈 소스 프레임 워크이므로 나머지 답변에서는이 널리 채택 된 접근 방식을 올바른 것으로 가정합니다. 프레임 워크 개발자가 다음을 수행 할 필요가 없습니다. 소비자가 어쨌든 그것을 다시 공동 디자인하기 때문에 코드 서명 ID를 사용하여 다른 개발자에게 프레임 워크를 배포합니다 .

iOS에만 적용되며 전적으로 개발자의 관심사 인 경험적 관찰 # 2

소비자는 개발자로부터받은 프레임 워크가 코드 서명되었는지 여부를 신경 쓰지 않지만, 그렇지 않으면 Xcode가 빌드하지 않기 때문에 개발자 가 빌드 프로세스의 일부로 iOS 프레임 워크를 코드 서명해야합니다CodeSign error: code signing is required for product type 'Framework' in SDK 'iOS 8.1' . Justin Spahr-Summers 를 인용하려면 :

OS X 프레임 워크는 빌드 할 때 코드 서명 할 필요가 없습니다. 안타깝게도 Xcode에서는 빌드 할 때 iOS 프레임 워크를 코드 서명해야합니다.

이것은 내 질문 # 2에 대한 대답입니다. "iPhone Developer"ID는 Xcode를 연결하여 장치 용 iOS 프레임 워크를 구축하는 데 충분합니다. Carthage # 339에 대한이 의견 은 같은 것을 말합니다.

경험적 관찰 # 3 : 리포 도구

사러 도구의 특정 행동 : 프레임 워크 바이너리에 적용, 항상 반복적으로 그것에서 어떤 통합 설계 ID를 제거 : lipo -create/-remove codesigned framework ... -> not codesigned framework.

이것은 관찰 # 1의 모든 예제가 전혀 코드 서명되지 않은 이유에 대한 답이 될 수 있습니다. lipo를 적용한 후 코드 서명 ID가 날아가지만 관찰 # 1에 따르면 소비자가 신경 쓰지 않기 때문에 괜찮습니다.

이 관찰은 특히 AppStore에 대한 다음 관찰 # 4와 관련이 있습니다.

경험적 관찰 # 4 : 시뮬레이터 슬라이스가 포함 된 iOS 프레임 워크는 App Store에 제출할 수 없습니다.

이것은 Realm # 1163 및 Carthage # 188 에서 광범위하게 논의되며 레이더가 열립니다 : rdar : // 19209161 .

이는 전적으로 소비자의 관심사입니다. 소비자가 애플리케이션에 포함하는 iOS 범용 프레임 워크의 경우 애플리케이션이 빌드 될 때 앱이 AppStore 유효성 검사를 통과 할 수 있도록 해당 프레임 워크의 바이너리에서 시뮬레이터 슬라이스를 제거하는 특수 스크립트 (사용자 지정 실행 스크립트 단계)를 실행해야합니다.

Realm에서 찾은 바이너리 프레임 워크의 좋은 예 : strip-frameworks.sh .

그것은 사용 lipo이외의 다른 아키텍처의 모든 조각을 제거하기 위해 ${VALID_ARCHS}소비자의 신원과 다시 codesigns에게 다음과 -의 관찰 # 3 차기 곳이다 : 프레임 워크 때문에에 사러 조작의 재 codesigned해야한다.

Carthage에는 Consumer에 포함 된 모든 프레임 워크에 대해 동일한 작업을 수행하는 CopyFrameworks.swift 스크립트가 있습니다. 시뮬레이터 슬라이스를 제거하고 Consumer를 대신하여 프레임 워크를 다시 공동 설계합니다.

또한 좋은 기사 : Stripping Unwanted Architectures From Dynamic Libraries In Xcode .

---

이제 개발자와 소비자의 관점에서 iOS와 OSX를 모두 생산하는 데 필요한 단계에 대한 개요입니다. 먼저 더 쉬운 것 :

OSX

개발자:

1. OSX 프레임 워크 구축
2. 소비자에게 제공

개발자는 코드 서명 활동이 필요하지 않습니다.

소비자:

1. 개발자로부터 OSX 프레임 워크를받습니다.
2. 프레임 워크를 Frameworks / 디렉토리에 복사하고 "Code Sign on Copy"프로세스의 일부로 소비자를 대신하여 자동으로 코드 서명합니다.

iOS

개발자:

1. Builds iOS framework for device. Codesigning is required by Xcode, "iPhone Developer" identity is enough.
2. Builds iOS framework for simulator.
3. Uses lipo that produces universal iOS framework from previous two. At this point the codesigning identity of 1 step is lost: universal framework binary "is not signed at all" but that is fine since "Consumer does not care".
4. Gives it to Consumer

Consumer:

1. Receives iOS framework from Developer
2. Copies framework to Frameworks/ directory (this step may be redundant depending on what script in step 3 is.)
3. Uses special script as a part of build process: this script strips simulator slices off the iOS framework and then re-codesigns it on their, Consumer's, behalf.

---

From reading the linked thread on the Carthage repo it seems relatively simple. If you are distributing the binary framework you need to code sign it and if you are distributing the source via carthage or cocoa pods you do not as those tools take care of this via different methods.

The reason you need to code sign it when you distribute the binary framework is that Xcode won't produce a framework binary without code signing it. If you attempt to not code sign the binary framework you get this error:

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

It doesn't matter which identity you code sign the framework with (iPhone Developer or iPhone Distribution) because, as you point out, the framework will be re-codesigned with the "code sign on copy" setting. This means that your framework will be re-codesigned by the appropriate certificate from the framework consumer's developer profile when your framework is copied into their application. This means there will be no issues with the App Store as it will only see the final code signature from the framework consumer.

In the end of the day, you might as well code sign your .framework binary as you don't want to have to maintain an exotic build process, and as Xcode will only output signed frameworks you shouldn't move too far away from the defaults. It doesn't really matter anyway because the end consumer will be re-signing it.

---

Stanislav Pankevich's answer above is very valid and correct. But please note that as of Xcode 9.4, the IDE will ask you to disable code signing for iOS Cocoa Touch Frameworks. Apple here now says it is not recommended that you code sign your .framework.

I hope this helps.

참고URL : https://stackoverflow.com/questions/30963294/creating-ios-osx-frameworks-is-it-necessary-to-codesign-them-before-distributin