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

parfois, lorsque j'exécute une application sur un périphérique à partir de Xcode, j'essaie d'accéder au porte-clés, mais je échoue à cause d'une erreur -34018. Cela ne correspond à aucune des documentée trousseau codes d'erreur et ne peut pas être reproduits. (cela arrive peut-être 30% du temps, et je ne comprends pas pourquoi cela arrive). Ce qui rend le débogage de ce problème très difficile est le manque total de documentation. Une idée de ce qui cause ceci et comment le réparer? J'utilise Xcode 5 et j'exécute iOS 7.0.4 sur device.

il y a une question ouverte à ce sujet ici: https://github.com/soffes/sskeychain/issues/52

modifier: ajout d'un code d'accès par domaine clé par demande

j'utilise la bibliothèque SSKeychain pour interfacer avec le porte-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

la plupart du temps, c'est très bien. Parfois je vais frapper les échecs d'assertion où je ne suis pas capable pour écrire à ou lire à partir de porte-clés, provoquant l'échec d'assertion critique.

115
demandé sur NSTJ 2013-12-03 10:22:32

19 réponses

iOS 10 / Xcode 8 Fix:

Ajouter un Trousseau de Droit, Aller au projet paramètres- > capacités - > partage de porte-clés - > ajouter des groupes de porte-clés+activer

une réponse d'Apple:

mise à jour: nous avons enfin pu reproduire l'erreur -34018 sur iOS 8.3. C'est la première étape pour identifier la cause fondamentale et ensuite trouver une solution.

comme d'habitude, nous ne pouvons pas nous engager dans un calendrier de publication, touché de nombreux développeurs et nous voulons vraiment obtenir ce résolues.

plus tôt, j'ai suggéré d'ajouter un petit délai dans application: finishlaunchingwithoptions et applicationDidBecomeActive: avant d'accéder au porte-clés en tant que contournement. Cependant, cela ne semble pas réellement aider. Cela signifie que qu'il n'y a pas de solution connue pour le moment à part relancer App.

Le problème semble être lié à la pression de la mémoire, donc peut-être plus agressif dans la manipulation des avertissements de mémoire peut atténuer le problème

https://forums.developer.apple.com/thread/4743#14441

UPDATE

OK, voici la dernière.

C'est un problème complexe, avec de multiples causes possibles:

  • certaines instances du problème sont causées par des erreurs app de la signature. Vous pouvez facilement distinguer ce cas parce que le problème est reproductible à 100%.
  • certains cas du problème sont causés par un bogue dans la façon dont iOS supporte le développement d'applications (R. 23 991 853). Débogage cela a été compliqué par le fait qu'un autre bug dans L'OS (R. 23,770,418) masqué son effet, ce qui signifie que le problème n'a surgi quand l'appareil était en mémoire pression. Nous pensons que ces problèmes ont été résolus dans la résolution iOS 9.3.
  • nous soupçonnons qu'il pourrait y avoir d'autres causes de ce problème.

donc, si vous voyez ce problème sur un périphérique utilisateur (un qui n'a pas été parlé par Xcode) qui exécute iOS 9.3 ou plus tard, veuillez remplir un rapport de bogue à ce sujet. Essayez d'inclure l'appareil journal système dans votre rapport de bogue (je me rends compte que peut être délicat quand traiter avec les appareils du client; un option est de demander au client de installez Apple Configurator, qui leur permet de voir le journal du système). Et si vous enregistrez un bogue, merci de poster votre numéro de bogue, juste pour le dossier.

au nom D'Apple, je tiens à remercier tout le monde pour leur les efforts pour aider à traquer cette horrible question. Partager et Profiter de

https://forums.developer.apple.com/thread/4743#126088

43
répondu daidai 2016-09-19 18:19:47

en gros, vous devez co-concevoir votre .xcttest dossier en ajoutant ce qui suit comme un 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 en testant mon porte-clés sur l'appareil et cela a réussi à le corriger.

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

24
répondu JorgeDeCorte 2017-11-27 17:22:22

après inspection du code source . J'ai remarqué que les fonctionnalités du porte-clés sont accessibles via un démon de sécurité qui tourne dans son propre processus (séparé du processus app).

votre application et le processus securityd "parlent" ensemble à travers une technologie appelée XPC .

si nécessaire, la securityd est lancée via le commande de lancement par XPC. Vous pouvez probablement vérifier que le démon tourne dans L'application Activity Monitor (si elle tourne dans un simulateur bien sûr) et que son processus parent est lancé.

ma conjecture ici est qu'il est possible que pour une raison inconnue le démon de sécurité ne démarre pas ou ne le fait pas trop lentement et n'est pas prêt quand vous essayez de l'utiliser.

peut-être pourriez-vous penser à la façon de pré-lancer le démon.

Je m'excuse de ne pas être plus précis. J'espère que ça vous aidera à aller un peu plus loin dans vos enquêtes.

12
répondu Vincent Zgueb 2014-01-24 21:38:30

j'observe un comportement similaire après avoir créé et exécuté mon code dans Xcode 6 beta avec IOS 8 SDK (il fonctionne correctement avec Xcode 5 / iOS 7). Dans Xcode 6, dans iOS Simulator SecItemCopyMatching retourne toujours -34018. Il a commencé à fonctionner après avoir activé l'onglet "Partage de porte-clés" dans capacités.

cependant j'ai un autre problème. Je développe la bibliothèque statique, qui est utilisée par (entre autres) L'application de démonstration. La solution ci-dessus fonctionne pour L'application de démonstration projet, mais quand j'essaie de tester mon projet de bibliothèque statique, j'ai exactement la même erreur. Et le problème est que mon projet de bibliothèque statique n'a pas l'onglet capacités (car ce n'est pas l'application autonome).

j'ai essayé la solution postée ici par JorgeDeCorte, avec codesigning dans la cible de test, mais ça ne marche pas pour moi.

12
répondu Marcin 2014-06-09 12:38:16

Essayer la désactivation de tous les points d'arrêt lors du lancement de l'application de Xcode. Vous pouvez l'activer par la suite.

(aucune des solutions de rechange susmentionnées n'a fonctionné pour moi)

6
répondu HeTzi 2016-03-24 11:56:26

je viens d'avoir le même problème sur le simulateur fonctionnant 7.1 & 8.0. En faisant quelques recherches, j'ai remarqué que L'application Apple sample avait le partage de porte-clés activé pour ses capacités de cible. Je l'ai activé pour mon application qui a abouti à la création d'un fichier de versement que j'ai quitté avec les valeurs par défaut et maintenant je ne reçois plus d'erreurs -34018. Ce n'est pas idéal mais je vais vivre l'option de partage de porte-clés pour l'instant.

4
répondu Laurent 2014-06-08 07:16:22

j'ai été mordu par ceci, aussi et n'ai eu aucun succès avec aucun des autres solutions de rechange. J'ai ensuite nettoyé mes profils d'approvisionnement sur les appareils eux-mêmes en supprimant tous ceux liés à mon application ainsi que tous les profils de jokers (cela semble être le point). Pour ce faire, allez dans la fenêtre" Périphériques " de Xcode et cliquez avec le bouton droit de la souris sur votre téléphone (connecté):

cliquez sur " Afficher l'approvisionnement profils "et supprimer les profils connexes, et en particulier les profils d'équipe:

, y compris ceux avec l'astérisque. Après la réinstallation de l'application, tout est redevenu normal.

4
répondu k1th 2015-10-12 16:30:22

j'ai corrigé ce problème (je pense). J'avais sur mon appareil un profil de remplacement de Joker qui montrait qu'il n'avait pas d'identité de signature valide. J'avais aussi un profil de provision pour mon application qui était valide. Quand j'ai supprimé le profil Joker, j'ai arrêté d'avoir les erreurs -34018.

j'ai également fait en sorte que le code signant l'identité et le profil d'approvisionnement énumérés dans la section de signature de Code des paramètres de construction de la cible étaient identiques à celui pour le app (pas le générique "iPhone Developer")

3
répondu Dave Hirsch 2014-08-06 00:30:28

Codesigning A.XCTest bundle n'est pas aussi facile qu'il semble dans certains cas. Principalement JorgeDeCorte a raison avec sa réponse que la courte ligne donnée comme un Run Script est suffisant pour la plupart des devs. 

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

mais si vous avez plusieurs certificats dans votre porte-clés 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. Pour sûr, ce n'est pas idéal, mais à ma connaissance, vous n'avez aucune chance d'obtenir le certificat que Xcode 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  }'`

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
2
répondu CipherCom 2017-05-23 12:32:35

je recevais des -34018 erreur dans mon application (iOS 8.4) très rarement. Après une enquête, j'ai constaté que ce problème se produit lorsque l'application demande des données à partir du porte-clés trop souvent .

Par exemple, dans ma situation, il y avait deux demandes de lecture d'une clé spécifique en même temps provenant de différents modules d'application.

Pour corriger cela, je viens d'ajouter la mise en cache de cette valeur en mémoire

2
répondu somedev 2015-09-16 06:29:56

j'avais le même problème, du jour au lendemain, avec un appareil de test Xcode 6.2, iPhone 6, iOS 8.3. Pour être clair, cela n'a pas été expérimenté lors de l'exécution des tests Xcode, mais plutôt lors de l'exécution de l'application réelle sur mon appareil. Dans le simulateur, il n'y avait pas de problème, et jusqu'à tout récemment, il n'y avait aucun problème avec l'application elle-même.

j'ai essayé toutes les suggestions que j'ai pu trouver ici, telles que la suppression des profils d'approvisionnement sur mon appareil (j'ai supprimé tous les en activant temporairement la capacité de partage de porte-clés dans mon projet (même si nous n'en avons pas vraiment besoin), en m'assurant que mon compte de développement dans Xcode a été totalement mis à jour avec tous les certificats et les profils d'approvisionnement, etc. Rien n'a aidé.

puis j'ai Temporairement changé le niveau d'accessibilité de kSecAttrAccessibleAfterFirstUnlock à kSecAttrAccessibleAlwaysThisDeviceOnly , j'ai lancé l'application, et ça a bien fonctionné et j'ai pu écrire sur le porte-clés. Puis je l'ai changé en kSecAttrAccessibleAfterFirstUnlock , et le le problème semble avoir disparu "en permanence."

1
répondu Mason G. Zhwiti 2015-06-22 18:37:54

vient D'être mordu par ce bug sur Xcode 8 Beta 3. Le partage de porte-clés semble être la seule solution.

1
répondu XCool 2016-08-01 06:53:57

j'ai eu le même problème. Correction en mettant en place le partage de porte-clés.

1
répondu lumenela 2016-08-04 19:44:56

(ce n'est pas une réponse directe à l'OP de la question, mais qui peuvent aider les autres)

a commencé à obtenir le porte-clés error -34018 de façon uniforme dans le simulateur après avoir mis à jour Xcode de la version 7.3.1 à 8.0.

suite à ce conseil de daidai's answer ,

certaines instances du problème sont causées par une signature d'application incorrecte. Vous pouvez facilement distinguer ce cas parce que le problème est Reproductible à 100%.

il a été découvert que le profil D'approvisionnement avait d'une façon ou d'une autre été fixé à aucun dans les sections de signature de la cible.

toutefois, le fait de fixer les zones du profil D'approvisionnement à des valeurs valides n'était pas suffisant pour résoudre le problème en l'espèce.

une enquête plus poussée a révélé que le versement des avis Push affichait également une erreur. Il disait: "ajoutez la fonction Push Notifications à votre App ID."l'étape a été achevée, mais l'étape "Ajouter les Notifications Push, le droit aux allocations de fichier" n'a pas été.

après avoir appuyé sur" Fix Issue " pour corriger le problème de notification Push, l'erreur du porte-clés a été résolue.

pour cette cible particulière, le droit au" partage de porte-clés " avait déjà été activé à une certaine époque. L'éteignant, n'a pas causé le trousseau d'erreur réapparaît, donc il n'est pas clair si cela est nécessaire dans le cas.

1
répondu jk7 2017-05-23 10:31:06

dans iOS 9 j'ai éteint le désinfectant D'adresse et il a commencé à fonctionner sur l'appareil.

0
répondu pulse4life 2015-10-14 19:37:10

la seule solution qui a fonctionné pour moi A d'abord été de stocker nil pour la clé spécifiée, puis de stocker ma nouvelle valeur avec une opération séparée. Il échouerait en raison de l'erreur -34018 si j'ai essayé d'écraser la valeur existante. Mais aussi longtemps que j'ai stocké nil d'abord, alors la valeur mise à jour serait stockée avec succès immédiatement après.

0
répondu FranticRock 2015-10-24 01:53:36

j'ai rencontré ce problème -34018 aujourd'hui lors de L'exécution de L'API SecItemDelete. Ce que j'ai fait pour régler ce problème est: 1. Suite à @k1th solution https://stackoverflow.com/a/33085955/889892 2. Lancez le SecItemDelete dans le thread principal (auparavant, il est lu depuis le thread principal, donc alignez-le avec Supprimer).

Désolé, il s'agit une fois de plus :(

0
répondu Senry 2017-05-23 12:25:45

activez le partage de porte-clés dans les capacités de votre projet, il devrait résoudre le problème. enter image description here

0
répondu Rizwan Ahmed 2017-03-02 10:40:34

Ce qui a fonctionné pour moi

  • Trousseau de Partage.
  • utilisez le porte-clés Le moins possible et mettez en cache les données en mémoire, UserPreferences, disque, etc.
  • réessayez plusieurs fois les opérations de crudités de porte-clés si celles-ci échouaient.
  • Use DispatchQueue.sync pour le stockage/suppression / mise à jour des données.
0
répondu rockdaswift 2018-09-19 11:00:20