crypto: Enable overriding NSS DB location.

crypto: Enable overriding NSS DB location.

The NSS DB used by default is ~/.pki, in our layout tests we wish to override
this DB location so the user's configuration doesn't leak into the test run.

Provide a NSS_DEFAULT_DB_DIR environment variable to allow the path to be
changed. NSS_DEFAULT_DB_DIR was choosen because there is already a
NSS_DEFAULT_DB_TYPE (see
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Reference/NSS_environment_variables).

BUG=595504

[mithro, 2016-05-18 05:37:35]

tansell@chromium.org changed reviewers:
+ agl@chromium.org, davidben@chromium.org, rsleevi@chromium.org

[mithro, 2016-05-18 05:37:36]

Hi src/crypto/OWNERS,

I'm currently trying to fix http://crbug.com/595504. The root cause of this bug
is that our layout tests are using the user's ~/.pki code which on Goobuntu
machines ends up doing a whole bunch of complicated things. We would like to
make these tests use an isolated .pki directory and hence this CL.

Can you please take a look and tell me what you think?

Tim 'mithro' Ansell

[mithro, 2016-05-18 05:48:41]

Patchset #1 (id:1) has been deleted

[Ryan Sleevi, 2016-05-18 06:00:39]

rsleevi@chromium.org changed reviewers:
- agl@chromium.org, davidben@chromium.org

[Ryan Sleevi, 2016-05-18 06:00:39]

While I'm very sympathetic to the issues this is causing, I'm going to need to
push back on this and say Not LGTM, as I don't think this represents a good
solution, nor one we'd want to end up shipping.

That there are issues with Googler workstations is extremely unfortunate, and I
definitely think we want to escalate a resolution for a regression, but I'm not
sure this is materially different from other Google policies that negatively
affect the development and testing experience (I'm not sure how many of them to
mention here on the public bug, but I can think of a number of them).

I think the bug captures a reasonable set of tradeoffs, but I don't think this
is fundamentally different than if Google workstations were using buggy NVidia
drivers or 'sanctioning' something like loading Crypt32.dll from an alternative
path (aka how Windows does key management) or doing something like a
command-line flag for a custom keychain to try and bypass the system keychain.

There's already an existing path to work around this. We load NSS from
$HOME/.pki/nssdb - simply override $HOME in your tests, much like we
(effectively) require using xvfb-run . See how it's loaded from
https://code.google.com/p/chromium/codesearch#chromium/src/base/files/file_ut...
? That should be sufficient.

[mithro, 2016-05-18 06:35:40]

The problem is the user's .pki stuff leaking into what should be an isolated
test environment -- this affects *anyone* who has any type of .pki set up (it
just happens to be that Goobuntu users fall into this category). We also ignore
things like the system's proxy settings when running these tests.

Looking at other approaches;
 * Overriding $HOME means that Chrome can't connect to your X server. I could
try and link things like the ~/.Xauthority file and stuff...
 * Our build system doesn't allow me to build *just* content shell without NSS
support.

Do you have a suggestion or another option?

This file already seems to have a bunch of Chrome OS specific stuff for
overriding the nssdb path during testing?

Tim 'mithro' Ansell

[Ryan Sleevi, 2016-05-18 06:51:25]

On 2016/05/18 06:35:40, mithro wrote:
> The problem is the user's .pki stuff leaking into what should be an isolated
> test environment -- this affects *anyone* who has any type of .pki set up (it
> just happens to be that Goobuntu users fall into this category).

I'm aware. I went through the entire bug (and linked bugs) before commenting.
But I'm arguing this is no different from the fact that we use the user's X
server, or their Keychain, or their Crypt32.dll.

> We also ignore things like the system's proxy settings when running these
tests.

Not really (which is to say, it's more complicated than it looks).

> Looking at other approaches;
>  * Overriding $HOME means that Chrome can't connect to your X server. I could
> try and link things like the ~/.Xauthority file and stuff...

Our layout tests already handle XAUTHORITY as part of running tests (
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...
) which was, among other things, meant to address the need for hermeticism.

>  * Our build system doesn't allow me to build *just* content shell without NSS
> support.

That's correct. Because that's not supported.

On Linux, our use of NSS is helpful to think of like our use of X (or that may
be a bad example, with all the compositing changes going on). That is, it's a
core system feature. It's part of the LSB. It should not be treated differently
than a core OS service. So I'm not very keen on adding these sorts of
environment flags, especially when it's essentially a change to Chrome that is
specifically to support Googlers, on Google workstations, running Goobuntu, and
serves no other purpose. I appreciate this is a hard trade-off, but that's the
sort of tradeoff that leads to code bloat, superstition, and 'features' that can
never be removed.

> Do you have a suggestion or another option?

Well, our Windows developers have learned that developing on the Corporate
Windows image can be a severe impediment to their productivity. More recently,
our OS X users have encountered the same. So it's not without precedent that the
answer is "Don't develop on a corporate image", because Google's security needs
are at odds with our developers' needs.

I mention this because Google images have done weird stuff in the past as well
(particularly around Chrome sandboxing), and the answer there was, if you wanted
to work on that, you had to use a non-Google image. So again, it's not without
precedent.

I'm not trying to suggest "deal with it" or "get over it" as the answer, I'm
trying to suggest that the challenges faced here are not new, that the problem
is specific to Google, and that I think a reasonable goal should be finding a
way around this problem without changing any code. The moment we change code, we
will forever live with that and maintain it, and that's not something I'm
comfortable with, especially with the notion of doing that to Chrome to favour a
Google-specific, Google-localized configuration.

There's a variety of solutions to accomplish this without touching Chrome
sources. I mentioned overriding $HOME as one. You could always LD_LIBRARY_PATH
as another (for example, to hide the PKCS#11 module that's trying to be loaded).
But fundamentally, the goal as stated in this CL - "The user's configuration
doesn't leak into the test run" - is not something I'm supportive of. This is
part of the system configuration. It necessarily leaks into the test run.
Controlling that is something that I believe should be done outside of the
Chrome binary, and with the appropriate awareness that we're trying to 'lie' to
the code.

[mithro, 2016-05-18 07:41:50]

It sounds like I'm not going to convince you otherwise, but thought I would add
a couple of other points;

 * SUSE seems to have shipped (at some point) a modified version of Firefox,
Thunderbird, SeaMonkey, *Chromium* and Evolution which support;

   export NSS_SHARED_DB_PATH=$HOME/.pki/nssdb
   export NSS_USE_SHARED_DB=1

 * Firefox uses it's own database in the user's Firefox profile rather than
~/.pki/nssdb

 * OpenOffice and LibreOffice have a MOZILLA_CERTIFICATE_FOLDER environment
variable which can be set to anything.

 * If we have a layout test which adds a certificate which it doesn't clean up,
that certificate will now be used by any Chrome based browser.

 * There seems to be a "nodb_init" flag on line 723?

I'll go back to putting a hacky, Goobuntu specific, workaround into
run-webkit-tests.

Tim 'mithro' Ansell

[Ryan Sleevi, 2016-05-18 08:15:41]

On 2016/05/18 07:41:50, mithro wrote:

I know it seems like I'm being a pain about this. I appreciate you looking for
alternative solutions, and I'm sorry that it no doubt is frustrating. I assure
you I'm not trying to be a pain for a pains sake.

>  * Firefox uses it's own database in the user's Firefox profile rather than
> ~/.pki/nssdb

Firefox, as shipped by Mozilla (not distros), uses a hermetic copy of NSS, and
thus uses a hermetic copy of the cert database (because you can't mix DB
versions and NSS versions). We intentionally and explicitly have chosen not to
do this.

However, as shipped by many distros, the version of NSS shipped as part of the
system image will do all sorts of things. For example, as shipped by
RHEL/Fedora/CentOS, they force-load a variety of things in /etc and
system-related configurations. Which is exactly what Chromium picks up (on those
platforms), since NSS is being treated as part of LSB. 

>  * OpenOffice and LibreOffice have a MOZILLA_CERTIFICATE_FOLDER environment
> variable which can be set to anything.

Right, that's because NSS-as-deployed has been transitioning from single-app
mode (e.g. as with Firefox) into shared-mode (largely driven by
RHEL-and-friends), where shared is system-configured and non-user-overridable.
But even MOZILLA_CERTIFICATE_FOLDER was a workaround that predated the shared
DB.

I mention this mostly as an example of where something ends up "supported"
forever, with no clear understanding about who's using it, why it's being used,
or what would break if it was removed.

>  * If we have a layout test which adds a certificate which it doesn't clean
up,
> that certificate will now be used by any Chrome based browser.

Layout tests can't add certificates anymore (we explicitly removed the
application/x-x509-user-cert code), but otherwise, yes, this is true *on all
platforms*.

>  * There seems to be a "nodb_init" flag on line 723?

It's legacy code we haven't removed yet, but can safely be done so. It was from
when we used NSS more broadly (and was part of loading NSS into sandboxed
renderer processes for rendering). There's a ton of cleanup work related to NSS
that still needs to be done, especially around some of the TPM initialization
code (also in that file), now that we've transitioned off NSS for cryptographic
services. However, setting that would make all sorts of other things fail (was
never a supported config in the browser process on Linux).