net: lookup OCSP cache function with dlsym.

net: lookup OCSP cache function with dlsym.

Weak symbols are either broken or they don't work the way that we need.
Either way, the current weak symbol based scheme is causing
runtime-linker aborts on systems without NSS 3.12.6.

This change switches to using dlsym to lookup the symbol at runtime.

BUG=69345
TEST=Run chrome on systems with libnss.so < 3.12.6

[wtc, 2011-01-18 19:57:01]

LGTM.  There is a Windows (and perhaps Mac) compilation error
noted with "BUG" below.  Also, should we use LazyInstance
instead of Singleton?  I don't know how they differ, but
willchan seems to prefer LazyInstance.

http://codereview.chromium.org/6250008/diff/1/net/socket/ssl_client_socket_ns...
File net/socket/ssl_client_socket_nss.cc (right):

http://codereview.chromium.org/6250008/diff/1/net/socket/ssl_client_socket_ns...
net/socket/ssl_client_socket_nss.cc:51: #include <dlfcn.h>
BUG: this #include needs to be protected with an ifdef
because ssl_client_socket_nss.cc is also used on Windows.

You can use #if defined(OS_LINUX) to match the ifdef at
line 117.

http://codereview.chromium.org/6250008/diff/1/net/socket/ssl_client_socket_ns...
net/socket/ssl_client_socket_nss.cc:126: // RuntimeLIBNSSFunctionPointers is a
singleton which caches the results of any
Nit: LIBNSS => LibNSS

http://codereview.chromium.org/6250008/diff/1/net/socket/ssl_client_socket_ns...
net/socket/ssl_client_socket_nss.cc:2026:
GetCacheOCSPResponseFromSideChannelFunction()) {
Nit: it would be nice to save the return value of
GetCacheOCSPResponseFromSideChannelFunction() in a local
variable, so that we can avoid the singleton overhead.

[agl, 2011-01-18 20:29:45]

I think Singleton is correct here. LazyInstance<X> means that there can be
several X's but we really do only want a single function pointers object.

(i.e. if you wanted a 'singleton' map<string, string>, i.e. for a cache, then
that would be a LazyInstance because that's obviously not going to be the only
map<string, string>.

http://codereview.chromium.org/6250008/diff/1/net/socket/ssl_client_socket_ns...
File net/socket/ssl_client_socket_nss.cc (right):

http://codereview.chromium.org/6250008/diff/1/net/socket/ssl_client_socket_ns...
net/socket/ssl_client_socket_nss.cc:51: #include <dlfcn.h>
On 2011/01/18 19:57:01, wtc wrote:
> BUG: this #include needs to be protected with an ifdef
> because ssl_client_socket_nss.cc is also used on Windows.

Done, thanks.

http://codereview.chromium.org/6250008/diff/1/net/socket/ssl_client_socket_ns...
net/socket/ssl_client_socket_nss.cc:126: // RuntimeLIBNSSFunctionPointers is a
singleton which caches the results of any
On 2011/01/18 19:57:01, wtc wrote:
> Nit: LIBNSS => LibNSS

Done.

http://codereview.chromium.org/6250008/diff/1/net/socket/ssl_client_socket_ns...
net/socket/ssl_client_socket_nss.cc:2026:
GetCacheOCSPResponseFromSideChannelFunction()) {
On 2011/01/18 19:57:01, wtc wrote:
> Nit: it would be nice to save the return value of
> GetCacheOCSPResponseFromSideChannelFunction() in a local
> variable, so that we can avoid the singleton overhead.

Done.

[wtc, 2011-01-18 20:43:48]

LGTM!

http://codereview.chromium.org/6250008/diff/5001/net/socket/ssl_client_socket...
File net/socket/ssl_client_socket_nss.cc (right):

http://codereview.chromium.org/6250008/diff/5001/net/socket/ssl_client_socket...
net/socket/ssl_client_socket_nss.cc:100: #if defined(USE_SYSTEM_SSL)
Hmm... let's combine the #include <dlfcn.h> you added with
this one.

http://codereview.chromium.org/6250008/diff/5001/net/socket/ssl_client_socket...
net/socket/ssl_client_socket_nss.cc:2030: if (!predicted_cert_chain_correct_ &&
cache_ocsp_response) {
I assume predicted_cert_chain_correct_ is likely to be true,
so it is fine to call GetCacheOCSPResponseFromSideChannelFunction()
first even though its result may not be used in some cases.