web-dev-qa-db-fra.com

Test du trousseau - erreur OSStatus -34018

J'essaie de tester du code qui lit et modifie le trousseau en utilisant le framework SenTest de base sur Xcode. Le code fonctionne bien sur l'appareil, mais lorsque je démarre le test, j'obtiens ces erreurs chaque fois que je veux toucher le trousseau avec SecItemDelete/SecItemAdd/etc.

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

J'ai des profils de provisioning génériques correspondants (iOS Team Provisioning Profile: *) pour la cible de génération et la cible de test.

Ces réponses de débordement de pile (non confirmées):

la lecture des résultats du trousseau dans errSecItemNotFound 253

disons que j'ai besoin d'un profil d'approvisionnement correspondant à l'identifiant de mon application chaque fois que j'utilise le trousseau, mais cela ne peut pas être correct, sinon j'obtiendrais les mêmes erreurs en dehors de la cible de test.

En creusant plus profondément, les réponses (non confirmées) ici:

SecItemAdd et SecItemCopyMatching renvoie le code d'erreur -34018 (errSecMissingEntitlement)

impliquent qu'il pourrait y avoir un bug dans le trousseau et plus généralement Security.framework, ce qui est franchement terrifiant.

Ma question est; Quelqu'un a-t-il rencontré l'erreur OSStatus -34018 uniquement alors qu'il était sur une cible de test? Cela semble être le comportement que je vois.

EDIT: Ajout cette réponse que JorgeDeCorte utilisé dans sa réponse ci-dessous.

Ce thread semble contenir la solution si le problème se termine dans votre cible de test unitaire.

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

Fondamentalement, vous devez coder votre dossier .xcttest en ajoutant ce qui suit en tant que script d'exécution dans votre cible de test.

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

J'ai eu beaucoup d'erreurs -34018 lors du test de mon trousseau sur l'appareil et cela a réussi à le réparer.

Si le problème n'existe pas dans votre cible de test, ce n'est probablement pas la solution.

Donc je suppose que la solution est: forcer à signer votre cible de test.

iosiphonexcodesentestingkit
41
Andrew

Pour répondre à votre question: Oui, je rencontre le même problème. Cela semble fonctionner correctement lors de l'exécution de mon application. Mais lorsque j'exécute mes XCTests sur mon appareil, il semble que le trousseau renvoie l'erreur -34018. Ce qui est étrange, c'est que cela ne se produit pas lorsque je lance les tests sur le simulateur.

EDIT: J'ai trouvé une solution que j'ai expliquée dans cette réponse

6
JorgeDeCorte

J'ai obtenu cette erreur lors de la tentative d'exécution des opérations de trousseau via Grand Central Dispatch. Trouvez un moyen d'instancier votre trousseau (ou enveloppe de trousseau) sur le thread principal.

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

    });

//works fine
keychain = [[KeychainWrapper alloc] init];
4
Alex Stone

La signature de codes d'un bundle .xctest n'est pas aussi simple qu'il y paraît dans certains cas. Principalement JorgeDeCorte a raison avec son réponse que la ligne courte donnée en tant que Run Script est suffisant pour la plupart des développeurs.

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

Mais lorsque vous avez plusieurs certificats dans votre trousseau, cela échouera avec la ligne suivante

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

Une solution pour obtenir le bon certificat même avec plusieurs est ce court script. Bien sûr, ce n'est pas idéal, mais à ma connaissance, vous n'avez aucune chance d'obtenir le certificat que Xcode a trouvé et utilise pour signer votre .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
1
Patrik

J'ai également reçu "l'erreur OSStatus -34018". Je l'ai résolu en recréant mon profil d'approvisionnement.

1
vomako

J'ai également été incapable d'exécuter des tests impliquant le trousseau.

Ce qui a fonctionné pour moi a été d'ajouter une "application hôte" pour les tests. Vous pouvez le trouver en allant sur les cibles de votre projet, en appuyant sur "MyTestTarget", cliquez sur l'onglet "Général" et sélectionnez une "application hôte "avec une liste déroulante.

Je testais un framework CocoaTouch donc il n'y avait pas d'application Host pour cela. J'ai dû en créer un (ex. "MyFrameworkTestApp") juste pour les tests.

Si cela n'a pas aidé, vous pouvez également essayer d'aller dans l'onglet "Capacités" de la cible "MyFrameworkTestApp" et essayer d'activer la capacité "Partage de trousseau".

0
kgaidis