xcode - stickers - apple app store connect

¿Cómo se codifican los paquetes de marcos para Mac App Store?

Question

Después de una presentación reciente, recibí el siguiente error:

Firma no válida: el paquete de aplicaciones anidadas (FooBar.app/Contents/Frameworks/GData.framework) no está firmado, la firma no es válida o no está firmada con un certificado de envío de Apple. Consulte la Guía de firma de código y la Guía de espacio aislado de la aplicación para obtener más información.

Firma no válida: el paquete de aplicaciones anidadas (FooBar.app/Contents/Frameworks/Growl.framework) no está firmado, la firma no es válida o no está firmada con un certificado de envío de Apple. Consulte la Guía de firma de código y la Guía de espacio aislado de la aplicación para obtener más información.

Firma no válida: el paquete de aplicaciones anidadas libcurl (FooBar.app/Contents/Frameworks/libcurl.framework) no está firmado, la firma no es válida o no está firmada con un certificado de envío de Apple. Consulte la Guía de firma de código y la Guía de espacio aislado de la aplicación para obtener más información.

Así que firmé todos los paquetes marco por 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

La técnica 2206 dice:

Marcos de firma

Viendo que los marcos son paquetes, parece lógico concluir que se puede firmar un marco directamente. Sin embargo, éste no es el caso. Para evitar problemas al firmar marcos asegúrese de firmar una versión específica en lugar de todo el marco:

# Esta es la forma incorrecta:

codesign -s my-signing-identity ../FooBarBaz.framework

# Esta es la manera correcta:

codesign -s my-signing-identity ../FooBarBaz.framework/Versions/A

Y cuando trato de verificar los resultados, me parece bien:

% 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

Para divertirme, traté de firmar el paquete de marco directamente y todavía fue rechazado. Pero eso es exactamente lo que la documentación dijo que no debía hacer.

¿Alguna suposición de por qué eso sería considerado inválido? Estoy usando el mismo certificado que uso para firmar con código mi aplicación, la que funcionó en el pasado.

Mi única conjetura sería algo relacionado con los plists existentes (¿tengo que tener los identificadores en los Info.plists del marco?) O derechos, ¿alguna sugerencia?

Answer 1

Así es como lo arreglé;

• Ingresa a la configuración de compilación de tu objetivo
• En la línea "Otros indicadores de firma de código"
• Ingrese --deep value para el parámetro de lanzamiento
• Cerrar XCode
• Ingrese a la carpeta de datos derivados en su Mac y elimine los datos antiguos derivados (la ruta predeterminada es: / Users / YOUR_USER_NAME / Library / Developer / Xcode / DerivedData)
• Abre Xcode y compila

Después del archivo de compilación y envíe la aplicación nuevamente ...

Answer 2

Basado en la respuesta de baptr, he desarrollado este script de shell que codifica todos mis frameworks y otros recursos binarios / ejecutables auxiliares (tipos actualmente admitidos: dylib, bundle y elementos de inicio de sesión):

#!/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

1. Guárdelo en un archivo en su proyecto. Guardo mi copia en un subdirectorio de Scripts en la raíz de mi proyecto.
   • El mío se llama codesign-frameworks.sh .
2. Agregue una fase de compilación "Ejecutar script" inmediatamente después de su fase de compilación "Copiar marcos incrustados".
   • Puede llamarlo "Codesign Embedded Frameworks".
3. Pegue ./codesign-frameworks.sh (o lo que sea que haya llamado su secuencia de comandos anterior) en el campo de texto del editor de scripts. Utilice ./Scripts/codesign-frameworks.sh si almacena la secuencia de comandos en un subdirectorio.
4. Crea tu aplicación. Todos los marcos incluidos serán codificados.

Si aún así aparece el mensaje " Identidad : ambiguo (coincidencias: ...", por favor, coméntelo a continuación. Esto ya no debería suceder.

Actualizado el 14/11/2012: agregar soporte para marcos con caracteres especiales en su nombre (esto no incluye comillas simples) a "codesign-frameworks.sh".

Actualizado el 30/01/2013: agregando soporte para caracteres especiales en todas las rutas (esto debe incluir comillas simples) a "codesign-frameworks.sh".

Actualizado 2013-10-29: Agregar soporte experimental de dylib.

Actualizado el 28/11/2013: Adición de soporte de derechos. Mejorando el soporte experimental de dylib.

Actualizado el 14/06/2014: solucionando problemas de asignación de nombres con marcos que contienen marcos (anidados). Esto se hizo agregando la opción -depth para find , lo que hace que find haga un recorrido transversal en profundidad. Esto se ha vuelto necesario debido al problema que se describe aquí . En resumen: un paquete que contiene solo se puede firmar si sus paquetes anidados ya están firmados.

Actualizado el 29/06/2014: adición de soporte de paquete experimental.

Actualizado el 29/08/2014: mejora el código y prevención de fallas para restaurar IFS.

Actualizado el 26-09-2014: agregando soporte para los elementos de inicio de sesión.

Actualizado 2014-10-26: citas de las comprobaciones del directorio. Esto corrige los errores de "línea 31/42: demasiados argumentos" y el error resultante de "no se ha firmado el objeto de código" para las rutas que incluyen caracteres especiales.

Actualizado 2014-11-07: Resolviendo el error de identidad ambiguo (como "Desarrollador de Mac: ambiguo ...") al usar la resolución de identidad automática en Xcode. Ya no tiene que establecer explícitamente la identidad y solo puede usar "Desarrollador Mac".

Actualizado 2015-08-07: Mejorando la semántica.

Mejoras bienvenidas!

Answer 3

Su comentario muestra que firmó los objetos dentro del directorio de la versión del paquete. La técnica muestra firmar el directorio en sí.

Lo siguiente coincide mejor con la técnica:

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

Answer 4

Una cosa que no veo mencionada aquí es que necesita tener su Info.plist dentro de / Resources dentro del directorio del framework versionado. De lo contrario, obtendrá el error "formato de paquete no reconocido, no válido o no apto" cuando intente firmar el directorio versionado.

Proporcioné una respuesta más extensa aquí: Cómo diseñar CoCocer.framework para la aplicación Sandboxed para Mac