+sleevi since he's the one usually modifying this test when he uprevs NSS.

Is there a quick read on ImageTest and its limitations?

Interrogating the set of roots involves loading one (or more) DLLs and actively querying them. So long as we're maintaining that, I'm less concerned with the per-architecture aspects, and totally support improving test speed :)

It runs on the host system and only has access to the mounted Chrome OS image -- not to any Chrome OS runtime.

OK, then we probably won't be able to; the root store is expressed as a PKCS#11 module (you call the C_Initialize symbol on it), not as a static file config, so we'd need to be able to load and query that module.

(And also to make sure that no extra modules get added to the load sequencing, as Red Hat/Fedora have done)

I'm gonna mark this tentatively as infeasible for now since we do seem to need runtime components for this test.

the need to dlopen libnssckbi.so directly does seem to make this infeasible.  unless there's a sane way to extract the certs from that file via other tools.

So we definitely know the root certs that we're building into the NSS module (it's part of the certdata.txt in the build files), my big concern would be situations where additional root modules (such as Chaps technically can be) being introduced, or packages such as Red Hat/Fedoras, which replaces the NSS module with a shim module through a config file, and redirects all the roots to another location.

The current approach of extracting the roots via the nss-tools helper is capable of detecting those changes, hence the preference, but if it makes things easier and/or we think those risks are unrealistic, we can totally revisit this. After all, it's just tradeoffs :)