Force crypto::AppleKeychain access to be guarded by a Big Global Lock

net/base/cert_verify_proc_mac.cc

Index: net/base/cert_verify_proc_mac.cc
diff --git a/net/base/cert_verify_proc_mac.cc b/net/base/cert_verify_proc_mac.cc
index e47892970f034f18bc3486e0a6a92bd11b8a142b..9b6e28789b4cb43341b5bf07fec5d5c18c60b1ee 100644
--- a/net/base/cert_verify_proc_mac.cc
+++ b/net/base/cert_verify_proc_mac.cc
@@ -16,6 +16,8 @@
 #include "base/mac/scoped_cftyperef.h"
 #include "base/sha1.h"
 #include "base/string_piece.h"
+#include "base/synchronization/lock.h"
+#include "crypto/mac_security_services_lock.h"
 #include "crypto/nss_util.h"
 #include "crypto/sha2.h"
 #include "net/base/asn1_util.h"
@@ -362,11 +364,9 @@ int CertVerifyProcMac::VerifyInternal(X509Certificate* cert,
   // chain building.
   ScopedCFTypeRef<CFArrayRef> cert_array(cert->CreateOSCertChainForCert());
 
-  // From here on, only one thread can be active at a time. We have had a number
-  // of sporadic crashes in the SecTrustEvaluate call below, way down inside
-  // Apple's cert code, which we suspect are caused by a thread-safety issue.
-  // So as a speculative fix allow only one thread to use SecTrust on this cert.
-  base::AutoLock lock(verification_lock_);
+  // Serialize all calls that may use the Keychain, to work around various
+  // issues in OS X 10.6+ with multi-threaded access to Security.framework.
+  base::AutoLock lock(crypto::GetMacSecurityServicesLock());
 
   SecTrustRef trust_ref = NULL;
   status = SecTrustCreateWithCertificates(cert_array, trust_policies,