ios - Probando el llavero-OSStatus error-34018

iphone xcode

Question

Estoy intentando probar el código que lee y altera el llavero usando el marco básico de SenTest en Xcode. El código funciona bien en el dispositivo, pero cuando comienzo la prueba recibo estos errores cada vez que quiero tocar el llavero con SecItemDelete / SecItemAdd / etc.

The operation couldn''t be completed. (OSStatus error -34018 - client has neither application-identifier nor keychain-access-groups entitlements)

Tengo perfiles de aprovisionamiento de comodines coincidentes ( iOS Team Provisioning Profile: * ) tanto para el objetivo de compilación como para el objetivo de prueba.

Estas (no confirmadas) respuestas de desbordamiento de pila:

Leer de los resultados del llavero en errSecItemNotFound 25300

diga que necesito un perfil de aprovisionamiento que coincida con mi identificador de aplicación cada vez que use el llavero, pero eso no puede ser correcto, o obtendría los mismos errores fuera del objetivo de la prueba.

Al profundizar, las respuestas (no confirmadas) aquí:

SecItemAdd y SecItemCopyMatching devuelve el código de error -34018 (errSecMissingEntitlement)

implica que podría haber un error en el llavero y, en general, en Security.framework , lo que es francamente aterrador.

Mi pregunta es; ¿Alguien ha golpeado el error OSStatus -34018 solo cuando estaba en un objetivo de prueba? Ese parece ser el comportamiento que estoy viendo.

EDIT: Agregando esta respuesta que JorgeDeCorte usó en su respuesta a continuación.

Este hilo parece contener la solución si el problema existe en su objetivo de prueba de unidad.

https://devforums.apple.com/message/917498#917498

Básicamente, tiene que codificar su carpeta .xcttest agregando lo siguiente como un script de ejecución en su objetivo de prueba.

codesign --verify --force --sign "$CODE_SIGN_IDENTITY" "$CODESIGNING_FOLDER_PATH"

Recibí muchos errores -34018 al probar mi llavero en el dispositivo y esto logró solucionarlo.

Si el problema no existe en su objetivo de prueba, probablemente esta no sea la solución.

Así que supongo que la solución es: forzar el signo de tu objetivo de prueba

Answer 1

Codificar un paquete .xctest no es tan fácil como parece en algunos casos. Principalmente JorgeDeCorte tiene razón con su answer que la línea corta dada como un Run Script es suficiente para la mayoría de los desarrolladores.

codesign --verify --force --sign "$CODE_SIGN_IDENTITY" "$CODESIGNING_FOLDER_PATH"

Pero cuando tenga varios certificados en su llavero, esto fallará con la siguiente línea

iPhone Developer: ambiguous (matches "iPhone Developer: Your Name (ABC123DEF45)" and "iPhone Developer: Your Name (123ABC456DE)"

Una solución para obtener el certificado correcto, incluso con varios, es este breve script. Por supuesto, esto no es lo ideal, pero por lo que sé, no tiene la oportunidad de obtener el certificado que Xcode encontró y utiliza para firmar su .app.

echo "codesign --verify --force --sign /"$CODE_SIGN_IDENTITY/" /"$CODESIGNING_FOLDER_PATH/""
IDENTITIES=`security find-identity -v -s "Code Signing" | grep "iPhone Developer" | awk ''{ print $2 }''`
for SHA in $IDENTITIES; do
codesign --verify --force --sign $SHA "$CODESIGNING_FOLDER_PATH"
if [ $? -eq 0 ]; then
echo "Matching identity found: $SHA"
exit 0
fi
done;
exit 1

Answer 2

Para responder a su pregunta: Sí, tengo el mismo problema. Parece funcionar bien cuando ejecuto mi aplicación. Pero cuando ejecuto mis pruebas XCT en mi dispositivo, parece que el llavero devuelve el error -34018. Lo extraño es que no sucede cuando ejecuto las pruebas en el simulador.

EDIT: encontré una solución que he explicado en esta respuesta

Answer 3

Recibí este error al intentar ejecutar las operaciones de llavero a través de Grand Central Dispatch. Encuentre una manera de crear una instancia de su llavero (o envoltorio de llavero) en el hilo principal.

//results in code -34018
static dispatch_once_t token;
dispatch_once(&token, ^{
keychain = [[KeychainWrapper alloc] init];
});
//works fine
keychain = [[KeychainWrapper alloc] init];

Answer 4

También obtuve el error "OSStatus error -34018". Lo resolví recreando mi perfil de aprovisionamiento.