Open Bug 332426 Opened 18 years ago Updated 2 years ago

result of CERT_GetCertNicknames varies on different threads

Categories

(NSS :: Libraries, defect, P2)

3.11.1

Tracking

(Not tracked)

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
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
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.
The target milestone is already released. Resetting target milestone.
Target Milestone: 3.11.1 → ---
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.