Splitted from  bug 862043 .

The main issue here will be getting the list of certificates for the initial NetworkContext creation, as listing certs tends to be async, and we really don't want to make requests before these have been applied.
I'll see if I can find a nice way to do that.

Ideas under https://docs.google.com/document/d/1AwPIecUtYfjmkhVHTQzhnSB9WLl-Y8Cb_X225gu4J0w/edit#

Unfortunately, my ideas in comment #4 turned out to be not sufficient, as they would not support some usecases (see Ryan's comments).

Meanwhile, I have https://chromium-review.googlesource.com/c/chromium/src/+/1341832 as an example of a trust setting which does not seem to be automatically propagated to the OOP NetworkService.

(+lassey@ as we talked about the ideas in Comment #4 - which turned out to be insufficient - briefly on chat last week).

Thanks for the repro in comment 5, looks like that part of the webui doesn't work. I can confirm it's fixed by remoting the SetCertTrust() call to the network process.

Two thing that I found confusing:
-the first "EXPECT_TRUE(IsShowingInterstitial(tab));" always fails, even with network service disabled
-if I comment out that line the test passes. But then if I also comment out the second NavigateToURL (line 6125, and its accompanying IsShowingInterstitial()) the test fails. Why?

Note that SetCertTrust will, IIUC, mean that NSS will attempt to modify the DB from the network process too.

Re Test issues:
Interesting. I don't think I observed that yesterday(?) but doesn't seem to be racy, so not sure what I was observing exactly :-D
The issue is that EmbeddedTestServer runs RegisterTestCerts in its constructor unconditionally, so the server certificate is always accepted if the NetworkService runs in process.
I've changed the test to reset the TestRootCerts (see Patchset 3 of https://chromium-review.googlesource.com/c/chromium/src/+/1341832 ) and now it behaves as following for me:
(*) no additional flags -- passes
(*) --enable-features=NetworkService -- fails on L6140 (which is the last check)
(*) --enable-features=NetworkService,NetworkServiceInProcess -- passes
Which makes sense - if the cert verification is in the same process, it "sees" the change in trust.

BTW I just tried this manually (e.g. without the browsertest). It works with the network service enabled.

What I did (with release linux_chromeos builds):
1) sudo python net/tools/testserver/testserver.py --port=443 --https --cert-and-key-file=net/data/ssl/certificates/ok_cert.pem --data-dir=content/test/data
2) loaded https://127.0.0.0.1 and verified it gives cert error
3) imported root_ca_cert.pem in the settings webui and checked the SSL box (first one)
4) reloaded https://127.0.0.1 and verified it loads fine
5) edited the cert in the webui and removed the SSL checkbox
6) reloaded https://127.0.0.1 and got a cert error again


For the browser test, I added a
sleep(5);
before the last NavigateToURL and then it worked, so it seems like a timing issue with the test? (not sure why though)

Hrm, there's no explicit sync with the network service process so if NSS picks up this DB change (which has been performed by the browser process) automatically in the network process, it makes sense that it would be unspecified when that happens.

NSSCertDatabase::SetCertTrust ends up notifying CertDatabase::Observers, which NetworkService listens to and sends to the network process (see NetworkService::OnCertDBChanged).

As mentioned previously in various meetings, NSS explicitly does not guarantee when (or if) those changes will be made. The notification to CertDatabase::Observers is completely irrelevant to the propagation of trust settings.

For example, in the current implementation (which is not stable API nor ABI and must not be relied upon by NSS consumers, including Chrome), trust settings are cached in an entry that hangs off the certificate handle. If there exists a copy of that handle in the process already, the trust settings will not necessarily be recomputed (it varies based on which verification path is being taken and which API calls are made inbetween). Further, the propagation of trust settings is also dependent upon which third-party modules are being used; for example, Googler workstation machines are not suitable test environments, due to a third-party module being installed which is exceptionally 'chatty' and thus confounds several other NSS-related tests. Some of the test harnesses take explicit steps to mitigate this risks (e.g. via library preloads) so that local, Googler-specific configuration does not add test variability.

Again, this is not specified by NSS.

I tried this in a stock ubuntu install in a VM, and couldn't repro the bug.

In the absence of a repro that we can see, let's see if users report any issues related to this.

Adding this to Enteprise's radar, since the proposed path may cause data loss and corruption for our users, as well as potential security risk, due to relying on undefined behaviour, and will not be seen until later in the game.

Users who, for example, make use of NFS will be adversely affected by this, precisely because it's not a supported mode. Users who use Chrome may find the behaviour non-deterministic based on the sites they've been to and the state of the internal caches, and whether or not the object is refreshed.

+Drew as well since this affects CrOS