Chromium needs the equivalent of firefox-extension, maybe
Description (last modified by jdreed) (diff)
For things like the MIT CA, etc.
comment:1 Changed 9 years ago by davidben
Chromium caches in XDG_CACHE_HOME, so moving that to a local directory should be sufficient.
Milestone changed from Precise Release to Quantum Quetzalcoatl
Type changed from defect to enhancement
Summary changed from Chromium should not cache in ~ to Chromium needs the equivalent of firefox-extension, maybe
And we already moved XDG_CACHE_HOME in #1109, so we win.
We should consider if other extension-like things need to be done, though.
Some of these things may be useful.
http://www.chromium.org/administrators
Though I don't see a way to install the MIT CA. Probably because Chrome just uses the platform's native cert store, so it doesn't make sense to handle it themselves. Except Linux lacks the coordination to have a "native cert store"... Chrome uses the NSS shared DB stuff, but I'm unclear how much the /etc/pki/nssdb mentioned on that page actually exists.
https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX
I mean, is /usr/share/ca-certificates the "platform's native cert store"? Or can it be made to be?
Hrm, I don't think NSS knows to read that? That's what OpenSSL is configured against, right? It also doesn't cut it for a "platform native cert store". You need something that can store user client certs, private keys, and ideally user-supplied roots too. I think Fedora's trying to go the other direction and make everything use NSS instead.
http://fedoraproject.org/wiki/FedoraCryptoConsolidation
This bug seems relevant.
https://code.google.com/p/chromium/issues/detail?id=16387
It actually has a coherent explanation for how system-wide certs are supposed to work in NSS-shared-db-land. And it's a mess. Instead of opening ~/.pki/nssdb, you're supposed to open /etc/pki/nssdb which then references a glue library in pkcs11.txt which will also open ~/.pki/nssdb and merge it in. But that only exists in Fedora and so Chrome has to open ~/.pki/nssdb instead to work on Debian/Ubuntu?.
The bug also mentions a problem with /etc/ssl/certs (or /usr/share/ca-certificates) which is that it doesn't have trust flags. Ironically, I bet /usr/share/ca-certificates/mozilla is just extracted from NSS source with trust flags ignored anyway.
I can submit a proper patch for the /etc/pki/nssdb hack in the bug through the right code review tool, but that fixing that won't help Debathena since system-wide NSS DB is apparently only a thing in Fedora-land.
Priority changed from normal to low
Milestone changed from Current Semester to The Distant Future
I think this is on hold until a good upstream solution exists. We can also decide we don't care, since MIT server certs are now signed by a "real" CA. I'm not excited about the idea of a wrapper to populate ~/.pki/nssdb
Apparently Victor wrote chomium-config while I wasn't looking and it made it into -development?
davidben suggests it would be better to do this via the methods described at:
http://www.chromium.org/administrators/linux-quick-start
http://www.chromium.org/administrators/policy-list-3#AuthServerWhitelist
Victor's chromium-config (enabling idp.mit.edu for GSSAPI) went to production today.