Status: Untriaged Owner: [email protected] CC: [email protected], [email protected], [email protected] Labels: Type-Bug Pri-2 OS-All Area-Misc
New issue 5699 by [email protected]: X509Certificate::Cache should not use a certificate's fingerprint alone as the key for its std::map. http://code.google.com/p/chromium/issues/detail?id=5699 X509Certificate::Cache was added to reduce memory consumption by reducing the number of X509Certificate objects we have to create. It stores X509Certificate objects in a std::map using certificate fingerprint as the key. If we need to create a new X509Certificate object, and a cached X509Certificate object has the same certificate fingerprint as the new certificate, the new certificate is destroyed and the cached X509Certificate object is returned. This design ignores the fact that the OSCertHandle points not only to the certificate (uniquely identified by its fingerprint) but also properties of the certificate. The cached X509Certificate object may have different properties even though it contains the same certificate. For example, on Windows OSCertHandle is PCCERT_CONTEXT, which points to the CERT_CONTEXT structure: struct _CERT_CONTEXT { DWORD dwCertEncodingType; BYTE *pbCertEncoded; DWORD cbCertEncoded; PCERT_INFO pCertInfo; HCERTSTORE hCertStore; } CERT_CONTEXT; The first four fields should be the same for all CERT_CONTEXT structures representing the same certificate, but the last field, hCertStore, is a property that can be different. Under the current X509Certificate::Cache design, the hCertStore property is lost if we reuse a cached X509Certificate object. The obvious fix is to use the OSCertHandle as the key for the std::map in X509Certificate::Cache. In both NSS and Windows CryptoAPI, OSCertHandle points to a reference-counted type. So these crypto libraries could potentially cache their certificate objects internally. I'll need to look in the debugger to find out if they're actually doing that. To be sure that we regain the memory saving, I suggest that we remove the subject_, issuer_. valid_start_, and valid_expiry_ members and generate those values in the getters. The getters will need to be renamed GetSubject(), GetIssuer(), etc. to reflect their cost. (We already have such a getter, GetDNSNames().) What do you think of this proposal? -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Chromium-bugs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/chromium-bugs?hl=en -~----------~----~----~----~------~----~------~--~---
