Risoluzione

a. I have a crlcache.db reference that appears dead, but no number of deletion attempts makes it go away.

Questo era il problema di root, ma era difficile farlo andare via con uno qualsiasi degli strumenti esistenti. La voce crlcache.db era fantasma nella mia applicazione Accesso Portachiavi, quindi esisteva ancora una voce. Mentre avevo azzerato tutte le mie password, non avevo completamente ucciso il portachiavi. Tutte le applicazioni che ho elencato usavano il portachiavi per trovare le loro informazioni, colpendo crlcache.db e poi riprovando o gettando che dovevo rimuovere manualmente entrambi questi file (essenzialmente un hard-reset dell'intero portachiavi):

~/Library/Preferences/com.apple.security.plist
/Library/Preferences/com.apple.security.plist

Diagnosi

È stato molto difficile diagnosticare il problema perché nulla mi diceva quale file non esisteva. Questo commento , con il suo comando che ha raccolto informazioni sui bug per Apple, è stato il più utile. Questo ha prodotto un gigantesco% ditar.gz con un sacco di gadget diagnostici che mi hanno detto molto di più su quello che stava succedendo. Assicurati di correre con qualsiasi applicazione (s) è comportarsi male al momento.

sudo sysdiagnose securityd

Tra i tanti file di output di debug in testo semplice che ha prodotto, ce n'era uno grande chiamato fs_usage.txt , e quando l'ho aperto, ho potuto vedere migliaia di voci familiari

08:01:11.999993  getattrlist                            /private/var                                                                                                                                                          0.000003   Twitter.3616
08:01:11.999996  getattrlist                            /private/var/db                                                                                                                                                       0.000003   Twitter.3616
08:01:11.999998  getattrlist                            /private/var/db/crls                                                                                                                                                  0.000003   Twitter.3616
08:01:12.000000  getattrlist            [  2]           /private/var/db/crls/crlcache.db                                                                                                                                      0.000002   Twitter.3616
08:01:12.000004  statfs64                               /private/var/db/crls      

Una volta che l'ho visto, era chiaro che il portachiavi era ancora il problema, e la mia voce fantasma doveva andare. Mancando la conoscenza di come eseguire la chirurgia laparoscopica sui file plist, ho semplicemente amputato e ricominciato.

Nel mio caso dopo aver rimosso Espionage ha lasciato un riferimento per il suo file .keychains in Accesso Portachiavi. Le voci del registro erano come queste:

default 15:11:56.715938 +0200   com.apple.WebKit.Networking DbOpen of /Volumes/1Tb/Users/MyUser/Library/Application Support/Espionage/Espionage.keychain
default 15:11:56.716702 +0200   com.apple.WebKit.Networking open /Volumes/1Tb/Users/MyUser/Library/Application Support/Espionage/Espionage.keychain: No such file or directory
default 15:11:56.716765 +0200   com.apple.WebKit.Networking CSSM Exception: -2147413737 CSSMERR_DL_DATASTORE_DOESNOT_EXIST
default 15:11:56.716848 +0200   com.apple.WebKit.Networking CSSM Exception: -2147413737 CSSMERR_DL_DATASTORE_DOESNOT_EXIST
default 15:11:56.716910 +0200   com.apple.WebKit.Networking CSSM Exception: -2147413737 CSSMERR_DL_DATASTORE_DOESNOT_EXIST
default 15:11:56.716952 +0200   com.apple.WebKit.Networking dbBlobVersion() failed for a non-existent database

La risoluzione era piuttosto semplice: dovevo rimuovere il riferimento al database in Accesso Portachiavi usando la voce di menu in File chiamata Delete Keychain Espionage . Dovresti provare a trovare il riferimento file mancante in una riga DbOpen prima delle righe CSSM Exception per vedere cosa manca.