On Mon, 2016-08-15 at 15:23 +0100, David Woodhouse wrote: > > Obviously I've added nothing that *uses* this yet; Varun is currently > working on tidying that up for submission as part of his GSoC project.
Here's the first use of it, and a request for opinions... The first patch adds a PK11_GetTokenUri() function, and uses it in the output of 'certutil -U'. Early on, we decided to cache the generated URI strings *in* the object from which it was generated — in this case, the struct PK11SlotInfoStr. This has the advantage that the caller doesn't need to free the returned string. However, on reflection I'm starting to think that the added complexity of ensuring that it's initialised and freed correctly — and especially the locking gymnastics required to ensure that it's generated in a thread-safe manner — are not worth the benefit. Especially since there are *options* when generating a URI to represent an object like a certificate — you may wish to specify the token on which it was found, or you may which to specify the object by CKA_ID and CKA_LABEL such that a subsequent match might find it on *any* token. If we have a one-size-fits-all cached answer, we can't offer those options. Also, early on in the project we were just using a hack to call into the system shared libp11-kit library. In importing that functionality into NSS for real, I've use PR_sprintf_append() for generating the URI strings and I've offered a P11URI_FreeString() function which callers *can* use to safely free the strings, which we didn't have at all in the first place. So on the whole I'm inclined to suggest that we ditch the caching idea (as shown in the final patch) and just let the caller free the string which is returned by the XXXX_GetXxxx_Uri() functions we're about to add. Opinions? Bob? -- David Woodhouse Open Source Technology Centre david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
