mojave mac duet apple app ios code-signing ios-frameworks

ios - duet - macos mojave



Creación de marcos iOS/OSX: ¿es necesario codificarlos antes de distribuirlos a otros desarrolladores? (3)

Estoy aprendiendo cómo crear marcos iOS y OSX. Tomemos iOS por ejemplo, los siguientes pasos me funcionan hasta ahora:

  1. Marco xcodebuild usando -sdk iphonesimulator y Build action
  2. Marco xcodebuild usando -sdk iphoneos y Build action
  3. Use la herramienta lipo para crear un binario universal para que lipo -info produzca lo esperado:

Las arquitecturas en el archivo fat: Foo.framework / Foo son: i386 x86_64 armv7 arm64

Las preguntas son:

  1. Leí que mi desarrollador puede volver a firmar mi marco de trabajo que lo está usando: "Código de inicio de sesión en la copia", pero no entiendo cuáles son las condiciones previas para ello, es decir, si debo agregar el paso de firma de código para firmar ese binario universal con mi identidad de firma antes ¿distribuirlo a otros desarrolladores?

  2. si anterior es positivo, ¿debería usar mi identidad de "Distribución de iPhone: ..." o "Desarrollador de iPhone: ..."? Es suficiente (para que mi marco como parte de algún proyecto de iOS pase todo tipo de validaciones, especialmente la validación de la tienda de aplicaciones ) ?.

El fondo para mi respuesta es el "error de CodeSign: se requiere la firma de código para el tipo de producto ''Framework'' en SDK ''iOS 8.3''" que he visto en varios marcos de terceros y Carthage#235 o "el objeto de código no está firmado en absoluto "(un ejemplo: problema que informé en Realm#1998 .

Por lo tanto, quiero asegurarme de que los usuarios de mis marcos no encuentren ningún problema de firma de códigos cuando los usen.

PD: Esta pregunta se vuelve aún más interesante cuando se aplica no a un único desarrollador sino a una organización que es un proveedor de marcos.

Abrí la recompensa: "Buscando una respuesta basada en fuentes creíbles y / u oficiales". pero no he recibido tal desde entonces.

Si bien la respuesta proporcionada por @jackslash es correcta, solo cuenta una parte de la historia, así que quiero escribir la mía de una manera que me gustaría haberla visto en el momento en que estaba haciendo esta pregunta.

La actualidad de esta respuesta es: julio de 2015. Es muy probable que las cosas cambien.

En primer lugar, afirmemos que las acciones necesarias para la firma correcta del código del marco deben dividirse en pasos que el Desarrollador del marco debe tomar y pasos que el Consumidor del marco debe tomar.

TLDR;

Para el marco OSX: el Desarrollador es libre de distribuir el marco OSX sin codificarlo, ya que el Consumidor volverá a codificarlo de todos modos.

Para el marco de iOS: el desarrollador es libre de distribuir el marco de iOS sin codificarlo, ya que el consumidor volverá a codificarlo de todos modos, pero Xcode obliga al desarrollador a codificar su marco cuando compila para un dispositivo iOS.

Debido al radar: "Los marcos de iOS que contienen segmentos de simulador no pueden enviarse a la tienda de aplicaciones" El marco de consumidor de iOS se ve obligado a ejecutar secuencias de comandos especiales como "copy_frameworks" o "strip_frameworks", que utiliza lipo -remove para quitar segmentos de simulador de iOS framework y re-codesigns framework despojado porque en este punto su identidad de codeigning sea lo que sea (o no fue) se elimina como efecto secundario de la manipulación de lipo -remove .

La respuesta más larga sigue.

Esta respuesta no es un "dibujo de fuentes creíbles y / u oficiales", sino que se basa en una serie de observaciones empíricas.

Observación empírica # 1: al consumidor no le importa porque volverán a codificar el marco que reciben del desarrollador

Las distribuciones de marco binario de proyectos de código abierto bien conocidos en Github no están codificadas . El comando codesign -d -vvvv proporciona: "el objeto de código no está firmado en absoluto" en todos los marcos binarios de iOS y OSX que solía explorar. Algunos ejemplos: ReactiveCocoa and Mantle , Realm , PromiseKit .

A partir de esta observación, está claro que los autores de estos marcos pretenden que sean codificados por el Consumidor, en su nombre, es decir, un Consumidor debe usar el indicador "Firmar código en la copia" en la fase de compilación de "Incrustar marcos" proporcionada por Xcode o usar algún shell personalizado script que hace lo mismo de forma manual: framework de codeigns en nombre del consumidor.

No encontré ningún ejemplo único de lo contrario: marco de código abierto que se distribuiría con identidad de firma de código en él, por lo que en el resto de la respuesta estoy asumiendo que este enfoque ampliamente adoptado es el correcto: no hay necesidad de que el Desarrollador de marco distribuir su marco de trabajo a otros desarrolladores con identidad de firma de código porque el consumidor de todos modos volverá a codificarlo .

Observación empírica # 2 que se aplica solo a iOS y que es completamente una preocupación del desarrollador

Si bien al consumidor no le importa si el marco que recibe del desarrollador está firmado o no con CodeSign error: code signing is required for product type ''Framework'' in SDK ''iOS 8.1'' , el desarrollador aún debe CodeSign error: code signing is required for product type ''Framework'' in SDK ''iOS 8.1'' su marco iOS como parte de su proceso de compilación cuando lo CodeSign error: code signing is required for product type ''Framework'' in SDK ''iOS 8.1'' para dispositivos iOS porque de lo contrario Xcode no se construye: CodeSign error: code signing is required for product type ''Framework'' in SDK ''iOS 8.1'' . Para citar a Justin Spahr-Summers :

Los marcos de OS X no necesitan estar firmados con código en la compilación ... Desafortunadamente, Xcode requiere que los marcos de iOS estén firmados con código en el momento de la construcción.

Esto responde bastante bien a mi pregunta # 2: la identidad del "Desarrollador de iPhone" es suficiente para engatusar a Xcode para que construya el marco de iOS para el dispositivo. Este comentario sobre Cartago # 339 dice lo mismo.

Observación empírica # 3: herramienta lipo

Comportamiento específico de la herramienta lipo: cuando se aplica al marco binario, siempre elimina de forma recursiva cualquier identidad de lipo -create/-remove codesigned framework ... -> not codesigned framework : lipo -create/-remove codesigned framework ... -> not codesigned framework .

Esta podría ser una respuesta de por qué todos los ejemplos en la observación n. ° 1 no están codificados en absoluto: su identidad de firma de códigos se desvanece después de que se aplica la lipo, pero dado que según la observación n. ° 1 al consumidor no le importa, está bien.

Esta observación es especialmente relevante para la siguiente observación # 4 sobre AppStore.

Observación empírica # 4: los marcos de iOS que contienen segmentos de simulador no se pueden enviar a la App Store

Esto se discute ampliamente en: Realm#1163 y Carthage#188 y se abre el radar: rdar: // 19209161 .

Esto es totalmente una preocupación del consumidor: para el marco universal de iOS que el consumidor incluye en su aplicación, cuando se está construyendo la aplicación, deben ejecutar un script especial (Fase de ejecución de script personalizada) que elimine el corte del simulador del binario de ese marco para que la aplicación pueda pasar la validación de AppStore.

El buen ejemplo para marcos binarios que encontré en Realm: strip-frameworks.sh .

Utiliza lipo para eliminar todas las secciones de arquitecturas que no sean ${VALID_ARCHS} y luego lo vuelve a codificar con la identidad del Consumidor ; aquí es donde entra en ${VALID_ARCHS} observación n. ° 3: el marco debe volver a codificarse debido a las manipulaciones de lipo en él.

Carthage tiene el script CopyFrameworks.swift que hace lo mismo con todos los marcos incluidos por Consumer: elimina los segmentos del simulador y vuelve a codificar el marco en nombre del consumidor.

También hay un buen artículo: Eliminación de arquitecturas no deseadas de bibliotecas dinámicas en Xcode .

Ahora, la descripción general de los pasos necesarios para producir tanto iOS como OSX desde las perspectivas del desarrollador y del consumidor. Primero el más fácil:

OSX

Desarrollador:

  1. Construye el marco OSX
  2. Se lo da al consumidor

No se requieren actividades de firma de códigos del Desarrollador.

Consumidor:

  1. Recibe el marco OSX del desarrollador
  2. Copia el marco al directorio Frameworks / y lo codifica automáticamente en su nombre, como parte del Consumidor, como parte del proceso de "Firma de código en copia".

iOS

Desarrollador:

  1. Construye el marco de iOS para el dispositivo. Xcode requiere la codificación, la identidad del "Desarrollador de iPhone" es suficiente.
  2. Construye el marco de iOS para el simulador.
  3. Utiliza lipo que produce el marco universal de iOS de los dos anteriores. En este punto, se pierde la identidad de firma de códigos de 1 paso: el marco binario universal "no está firmado en absoluto", pero eso está bien ya que "al consumidor no le importa".
  4. Se lo da al consumidor

Consumidor:

  1. Recibe el marco de iOS del desarrollador
  2. Copia el marco al directorio Frameworks / (este paso puede ser redundante dependiendo de qué script se encuentre en el paso 3).
  3. Utiliza una secuencia de comandos especial como parte del proceso de compilación: esta secuencia de comandos elimina los segmentos del simulador del marco de iOS y luego lo vuelve a codificar en su nombre, en nombre del consumidor.

Al leer el hilo vinculado en el repositorio de Cartago, parece relativamente simple. Si está distribuyendo el marco binario, debe codificarlo, firmarlo y si está distribuyendo la fuente a través de carthage o vainas de cacao, no lo hace, ya que esas herramientas se encargan de esto a través de diferentes métodos.

La razón por la que necesita firmar el código cuando distribuye el marco binario es que Xcode no producirá un marco binario sin código que lo firme. Si intenta no firmar el código del marco binario, obtendrá este error:

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

No importa con qué identidad codifique firmar el marco con (Desarrollador de iPhone o Distribución de iPhone) porque, como usted señala, el marco se volverá a codificar con la configuración de "firma de código en la copia". Esto significa que su marco se volverá a codificar mediante el certificado correspondiente del perfil de desarrollador del consumidor del marco cuando su marco se copie en su aplicación. Esto significa que no habrá problemas con la App Store, ya que solo verá la firma del código final del consumidor del marco.

Al final del día, también puede firmar con código su binario .framework ya que no quiere tener que mantener un proceso de construcción exótico, y como Xcode solo generará marcos firmados, no debe alejarse demasiado del valores predeterminados Realmente no importa de todos modos porque el consumidor final lo volverá a firmar.

La respuesta de Stanislav Pankevich anterior es muy válida y correcta. Pero tenga en cuenta que a partir de Xcode 9.4, el IDE le pedirá que desactive la firma de código para iOS Cocoa Touch Frameworks. Apple aquí ahora dice que no se recomienda que firmes tu código .framework.

Espero que esto ayude.