iOS / OSX 프레임 워크 만들기 : 다른 개발자에게 배포하기 전에 코드 서명이 필요합니까? 내 서명 ID로 해당

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 에서보고 한 문제 .

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

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



답변

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

@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 프레임 워크에서 “코드 객체가 전혀 서명되지 않았습니다”를 제공합니다. 몇 가지 예 : ReactiveCocoaMantle , 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 # 1163Carthage # 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. 기기 용 iOS 프레임 워크를 빌드합니다. Xcode는 공동 디자인이 필요하며, “iPhone Developer”아이덴티티면 충분합니다.
  2. 시뮬레이터 용 iOS 프레임 워크를 빌드합니다.
  3. 이전 두 가지에서 범용 iOS 프레임 워크를 생성하는 lipo를 사용합니다. 이 시점에서 1 단계의 코드 서명 ID가 손실됩니다. 범용 프레임 워크 바이너리는 “전혀 서명되지 않았습니다”.하지만 “소비자가 신경 쓰지 않기 때문에”괜찮습니다.
  4. 소비자에게 제공

소비자:

  1. 개발자로부터 iOS 프레임 워크를받습니다.
  2. 프레임 워크를 Frameworks / 디렉토리에 복사합니다 (이 단계는 3 단계의 스크립트에 따라 중복 될 수 있습니다.)
  3. 빌드 프로세스의 일부로 특수 스크립트를 사용합니다.이 스크립트는 iOS 프레임 워크에서 시뮬레이터 슬라이스를 제거한 다음 소비자를 대신하여 다시 공동 설계합니다.


답변

Carthage repo에서 링크 된 스레드를 읽어 보면 비교적 간단 해 보입니다. 바이너리 프레임 워크를 배포하는 경우 코드 서명이 필요하고 카르타고 또는 코코아 포드를 통해 소스를 배포하는 경우 해당 도구가 다른 방법을 통해이 문제를 처리하지 않습니다.

바이너리 프레임 워크를 배포 할 때 코드 서명을해야하는 이유는 Xcode가 코드 서명 없이는 프레임 워크 바이너리를 생성하지 않기 때문입니다. 바이너리 프레임 워크에 코드 서명을하지 않으려면 다음 오류가 발생합니다.

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

지적했듯이 프레임 워크는 “코드 사인 온 카피”설정으로 다시 디자인 될 것이기 때문에 프레임 워크에 서명하는 ID (iPhone 개발자 또는 iPhone 배포)는 중요하지 않습니다. 즉, 프레임 워크가 애플리케이션에 복사 될 때 프레임 워크 소비자의 개발자 프로필에서 가져온 적절한 인증서로 프레임 워크가 다시 공동 설계됩니다. 즉, 프레임 워크 소비자의 최종 코드 서명 만 볼 수 있으므로 App Store에 문제가 없습니다.

하루가 끝나면 .framework 바이너리에 코드 서명을하는 것이 좋습니다. 이색적인 빌드 프로세스를 유지할 필요가없고 Xcode는 서명 된 프레임 워크 만 출력하므로 너무 멀리 이동해서는 안됩니다. 기본값. 최종 소비자가 다시 서명 할 것이기 때문에 어쨌든 실제로는 중요하지 않습니다.


답변