Don't initialize NSS in Cast renderers for the chimera build.

Don't initialize NSS in Cast renderers for the chimera build.

Cast has no need for NSS in renderers apart from the common crypto bits
(WebCrypto, //crypto), both of which will be BoringSSL in the chimera. Prepare
for that be switching to !USE_OPENSSL rather than USE_NSS_CERTS.

BUG=506323
Committed: https://crrev.com/4229ed54eee27211cfa6e34840e8c3bcbefdb582
Cr-Commit-Position: refs/heads/master@{#337835}

[davidben, 2015-07-07 23:20:01]

davidben@chromium.org changed reviewers:
+ gunsch@chromium.org, rsleevi@chromium.org

[davidben, 2015-07-07 23:20:01]

gunsch: Doug told me you folks have no special need for NSS in renderer anymore?

This CL is a no-op right now, but it won't be once I flip the switch for the
chimera.

This CL is assuming:
- Using //crypto inside a non-browser process is fine, (unless it's an obviously
NSS-specific interface).
- Using WebCrypto inside a non-browser process is fine.
- Using net::X509Certificate inside a non-browser process will break. (This
already doesn't work on most Chrome platforms.)
- Using NSS directly inside a non-browser process will break.

[gunsch, 2015-07-07 23:28:05]

+Doug, can you confirm? That seems accurate to me, though.

[gunsch, 2015-07-07 23:28:06]

+Doug, can you confirm? That seems accurate to me, though.

[dougsteed, 2015-07-08 02:53:21]

On 2015/07/07 23:28:06, gunsch wrote:
> +Doug, can you confirm? That seems accurate to me, though.

I am surprised to see that code, because I thought all initialization of NSS in
the renderer had been cleaned up. Before the upstreaming effort got underway, we
used to have our own code inside crypto::InitNSS and that is gone for sure.
Therefore our custom NSS module is definitely not being loaded in the renderer.
I think this whole chunk of code can probably go, but for now David's change is
OK.

[davidben, 2015-07-08 04:59:24]

On 2015/07/08 02:53:21, dougsteed wrote:
> On 2015/07/07 23:28:06, gunsch wrote:
> > +Doug, can you confirm? That seems accurate to me, though.
> 
> I am surprised to see that code, because I thought all initialization of NSS
in
> the renderer had been cleaned up. Before the upstreaming effort got underway,
we
> used to have our own code inside crypto::InitNSS and that is gone for sure.
> Therefore our custom NSS module is definitely not being loaded in the
renderer.
> I think this whole chunk of code can probably go, but for now David's change
is
> OK.

There's some weirdness in that NSS is used in WebCrypto (which need only be
keyed on USE_OPENSSL), but //content doesn't seem to actually initialize things.
But Ryan mentioned there's some question about the embedder setting sandbox
policies and weirdness?

All this is not long for the world so I'm just going to leave it as-is and just
set up the dominos for the removal once we can globally assume USE_OPENSSL is
set.

[gunsch, 2015-07-08 05:46:16]

lgtm

[Ryan Sleevi, 2015-07-08 11:08:23]

lgtm

[davidben, 2015-07-08 16:25:50]

The CQ bit was checked by davidben@chromium.org

[commit-bot: I haz the power, 2015-07-08 16:26:06]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1222193007/1

[commit-bot: I haz the power, 2015-07-08 16:30:59]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-07-08 16:32:18]

Patchset 1 (id:??) landed as
https://crrev.com/4229ed54eee27211cfa6e34840e8c3bcbefdb582
Cr-Commit-Position: refs/heads/master@{#337835}