Open
Bug 332426
Opened 18 years ago
Updated 2 years ago
result of CERT_GetCertNicknames varies on different threads
Categories
(NSS :: Libraries, defect, P2)
Tracking
(Not tracked)
NEW
People
(Reporter: alvolkov.bgs, Assigned: rrelyea)
Details
This randomness in order causing the tests to fail and is the reason for problem reported in https://bugzilla.mozilla.org/show_bug.cgi?id=332279. Randomness observed in multi-threaded environment only. To reproduce: Modify strsclnt sources to have static int active_threads = 1; /* number of threads currently trying to and recompiled strsclnt. Returned results are consistent with the following order: name TestUser49 name TestUser45-ec name TestUser45 name TestUser41-ec name TestUser41 name TestUser52-ec name TestUser52 name TestUser48-ec name TestUser48 name TestUser44-ec name TestUser44 name TestUser40-ec name TestUser40 name TestUser51-ec name TestUser51 name TestUser47-ec name TestUser47 name TestUser43-ec name TestUser43 name TestUser50-ec name TestUser50 name TestUser46-ec name TestUser46 name TestUser42-ec name TestUser42 name TestUser-ec name TestUser name TestUser49-ec Picked name TestUser49 Now set active_threads to 2: Picked name TestUser49-ec name TestUser49-ec name TestUser49 name TestUser45-ec name TestUser45 name TestUser41-ec name TestUser41 name TestUser52-ec name TestUser52 name TestUser48-ec name TestUser48 name TestUser44-ec name TestUser44 name TestUser40-ec name TestUser40 name TestUser51-ec name TestUser51 name TestUser47-ec name TestUser47 name TestUser43-ec name TestUser43 name TestUser50-ec name TestUser50 name TestUser46-ec name TestUser46 name TestUser42-ec name TestUser42 name TestUser-ec name TestUser Picked name TestUser49-ec name TestUser49 name TestUser45-ec name TestUser45 name TestUser41-ec name TestUser41 name TestUser52-ec name TestUser52 name TestUser48-ec name TestUser48 name TestUser44-ec name TestUser44 name TestUser40-ec name TestUser40 name TestUser51-ec name TestUser51 name TestUser47-ec name TestUser47 name TestUser43-ec name TestUser43 name TestUser50-ec name TestUser50 name TestUser46-ec name TestUser46 name TestUser42-ec name TestUser42 name TestUser-ec name TestUser name TestUser49-ec Picked name TestUser49
Comment 1•18 years ago
|
||
Attempting to clarify, a little. strsclnt uses the cert DBs in read-only mode. In an effort to find a cert for doing client auth, it calls CERT_GetCertNicknames to get the list of nicknames of "user" certs. Then it traverses the returned list of nicknames, looking for the first cert named in that list that was issued by a CA in the server's list of trusted CAs. It does this on many threads in parallel. The list returned by CERT_GetCertNicknames is different for each thread. The lists differ in the order of the list members. Consequently, the threads end up using different certs, even though they all attempted to find the cert using the exact same algorithm. The results of CERT_GetCertNicknames should be deterministic, given the same imputs. This is at least a P2.
Priority: -- → P2
Summary: CERT_GetCertNicknames: randomness in the order of cert nicks returned by the function → result of CERT_GetCertNicknames varies on different threads
Comment 2•18 years ago
|
||
If I had to take a guess the order changes because of certs getting cached and being pulled from different lists the first time around and later. It is certainly strange that the list order varies from thread to thread. But the CERT_GetCertNicknames API doesn't make any promise about the order, so it's difficult to even consider this a bug. The problem is really with the test application here which has multiple client certs matching the same CA and no algorithm to decide which one to use, other than the first in the list. The callback for automatic selection of client cert in SSL really works when only when one client cert matches - any more than that and it doesn't know what to do. The test application could be either fixed to specify a nickname, or the SSL callback could be fixed to sort the list it gets back, and then pick the first cert. We could add sorting to CERT_GetCertNicknames too, but I don't know if we should. Doing so is inefficient, and leaving it alone allowed us to find a bug in the test application.
Comment 3•17 years ago
|
||
The target milestone is already released. Resetting target milestone.
Target Milestone: 3.11.1 → ---
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•