There is a funciton in NSS, SECOID_AddEntry which was designed to allow applications to add OID's to NSS table of OID's. The function is not exported. Exporting the function would make it possible for applications to add OID's that NSS doesn't know about.
Created attachment 116588 [details] [diff] [review] Export AddOid. Fix AddOid to be useful. This patch is for NSS 3.8
Created attachment 117087 [details] [diff] [review] SEC_AddOidEntry should return SECOidTag, not SECStatus. Nelson caught this, not the Windows compiler. Note the function was returning a SECOidTag even though it was declared to return a SECStatus. SECStatus is an enum, not an int, so the compiler is getting to agressive in it's implicit casting...
Setting target to NSS 3.8
This code appears to do exactly what it says it does. But I have misgivings about exposing a method that is known not to be thread safe, yet has the potential to be used after initialization is done. NSS has reader/writer locks. Would performance be degraded unacceptably to use them to protect the OID hash tables?
If we expose this function, it needs to be thread safe. We should measure the performance degradation from the use of reader/writer locks to see if it is worthwhile to expose this function.
The current method for encoding cert names can only encode known OIDs. So before we can encode a name with an OID that's not compiled into secoid.c, we must add the OID it to the dynamic OID table. IOW, we must be able to add OIDs to the OID table on the fly, after initialization is done. IMO, this means the patch that doesn't make it thread safe isn't good enough. This bug blocks 211655, which blocks 210709.
Correct the dependency. This bug now blocks bug 210584, which blocks bug 210709.
Comment on attachment 117087 [details] [diff] [review] SEC_AddOidEntry should return SECOidTag, not SECStatus. Obsoleting patch as we decided that this function should be implemented in a thread-safe manner
I am fixing this bug as part of my work on bug 124923
I am making this bug be a dup of 124923 instead of merely depending on that bug. *** This bug has been marked as a duplicate of 124923 ***