117 votes

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

Parfois, quand je lance une application sur le périphérique à partir de Xcode, je voudrais essayer de le trousseau d'accès, mais ne parviennent pas en raison de l'erreur -34018. Cela ne correspond à aucune des documentée trousseau codes d'erreur et ne peut pas être reproduits. (se trouve peut-être 30% du temps, et il n'est pas clair pour moi pourquoi il arrive). Ce qui rend le débogage ce problème très difficile, c'est l'absence totale de documentation. Toute idée de ce qui cause de ce problème et comment le résoudre? Je suis en utilisant Xcode 5 et iOS 7.0.4 sur l'appareil.

Il y a un sujet ouvert à ce sujet ici: https://github.com/soffes/sskeychain/issues/52

EDIT: Ajout de keychain de code d'accès, conformément à la demande

Je suis à l'aide de l' SSKeychain librairie d'interfaçage avec un trousseau de clés. Voici l'extrait de code.

#define SERVICE @"default"

@implementation SSKeychain (EXT)

+ (void)setValue:(NSString *)value forKey:(NSString *)key {
    NSError *error = nil;
    BOOL success = NO;
    if (value) {
        success = [self setPassword:value forService:SERVICE account:key error:&error];
    } else {
        success = [self deletePasswordForService:SERVICE account:key error:&error];
    }
    NSAssert(success, @"Unable to set keychain value %@ for key %@ error %@", value, key, error);
    if (!success) {
        LogError(@"Unable to set value to keychain %@", error);
    }
    LogTrace(@"Will set keychain account %@. is to nil? %d", key, value == nil);
    if (value == nil)
        LogWarn(@"Setting keychain %@ to nil!!!", key);
}

+ (NSString *)valueForKey:(NSString *)key {
    NSError *error = nil;
    NSString *value = [self passwordForService:SERVICE account:key error:&error];
    if (error && error.code != errSecItemNotFound) {
        NSAssert(!error, @"Unable to retrieve keychain value for key %@ error %@", key, error);
        LogError(@"Unable to retrieve keychain value for key %@ error %@", key, error);
    }
    return value;
}

+ (BOOL)removeAllValues {
    LogInfo(@"Completely Reseting Keychain");
    return [[self accountsForService:SERVICE] all:^BOOL(NSDictionary *accountInfo) {
        return [self deletePasswordForService:SERVICE account:accountInfo[@"acct"]];
    }];
}

@end

Grande majorité du temps, c'est très bien. Parfois, je vais frapper l'affirmation des échecs où je suis incapable d'écrire ou de lire des porte-clés, provoquant des critiques échec d'assertion.

27voto

JorgeDeCorte Points 331

Ce fil semble contenir la solution si le problème des sorties dans votre unité-cible de test.

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

Fondamentalement, vous devez dessiner votre .xcttest dossier en ajoutant ce qui suit à titre d'exécuter un script dans votre cible de test.

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

J'ai eu beaucoup de -34018 erreurs lors de l'essai de mon trousseau sur l'appareil et c'réussi à le résoudre.

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

13voto

Vincent Zgueb Points 1193

Après avoir inspecté le code source. J'ai remarqué que le trousseau de clés fonctionnalités sont accessibles via une sécurité démon qui s'exécute dans son propre processus (séparée de l'application du processus).

Votre application et le securityd processus de "parler" ensemble au moyen d'une technologie appelée XPC.

Si nécessaire, le securityd est lancé via le bien-connu launchd commande par XPC. Vous pouvez certainement vérifier que le démon est en cours d'exécution dans le Moniteur d'Activité de l'Application (si en cours d'exécution dans le Simulateur de course) et que son processus parent est launchd.

Ma conjecture est ici qu'il est possible que, pour quelque raison inconnue, la sécurité démon ne parvient pas à démarrer ou de faire trop lentement et n'est pas prêt lorsque vous essayez de l'utiliser.

Peut-être que vous pourriez penser sur la façon de pré-lancement du démon.

Je m'excuse pour ne pas être plus précis. J'espère qu'elle pourra vous aider à aller un morceau plus loin dans vos investigations.

13voto

Marcin Points 420

Je suis en observant un comportement similaire après la création et l'exécution de mon code dans Xcode 6 bêta de l'iOS 8 SDK (elle fonctionne correctement avec Xcode 5 / iOS 7). Dans Xcode 6, dans le Simulateur iOS SecItemCopyMatching retourne toujours -34018. Il a commencé à travailler après la mise sur le "Trousseau de Partage" dans l'onglet Fonctionnalités.

Cependant j'ai une autre question. Je suis le développement de bibliothèque statique, qui est utilisé par (entre autres) de Démonstration de l'application. La solution ci-dessus fonctionne pour la Démo de l'application du projet, mais lorsque j'essaie de l'unité de test de mon projet de bibliothèque statique, j'ai exactement la même erreur. Et le problème, c'est que mon projet de bibliothèque statique n'a pas les Capacités de l'onglet (comme ce n'est pas l'application autonome).

J'ai essayé la solution posté ici par JorgeDeCorte, avec codesigning dans le test de la cible, mais il ne fonctionne pas pour moi.

4voto

John Difool Points 157

Je viens d'avoir le même problème sur le simulateur exécutant 7.1 & 8.0. Tout en creusant un peu, j'ai remarqué que l'application d'exemple Apple avait KeyChain Sharing activé pour ses capacités cibles. Je l'ai activée pour mon application, ce qui a entraîné la création d'un fichier de droit que j'ai laissé avec les valeurs par défaut. Désormais, je ne reçois plus d'erreur -34018. Ce n'est pas idéal, mais je vais vivre l'option de partage KeyChain pour le moment.

4voto

CipherCom Points 383

Codesigning un .xctest bundle n'est pas aussi facile qu'il y paraît dans certains cas. Principalement JorgeDeCorte est à droite avec sa réponse que la ligne courte en tant que Run Script est suffisant pour la plupart des devs.

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

Mais quand vous avez plusieurs certificats dans votre trousseau cela ne fonctionne pas avec la ligne suivante

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

Une solution pour obtenir le certificat de droit de même avec plusieurs en est ce petit script. Pour sûr, ce n'est pas l'idéal, mais comme, à ma connaissance, vous n'avez aucune chance d'obtenir le certificat que Xcode trouve et utilise pour la signature de 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

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X