Ticket #1185 (new enhancement)
Chromium needs the equivalent of firefox-extension, maybe
Reported by: | jdreed | Owned by: | |
---|---|---|---|
Priority: | low | Milestone: | The Distant Future |
Component: | -- | Keywords: | |
Cc: | Fixed in version: | ||
Upstream bug: |
Description (last modified by jdreed) (diff)
For things like the MIT CA, etc.
Change History
comment:2 Changed 12 years ago by jdreed
- Priority changed from high to normal
- Milestone changed from Precise Release to Quantum Quetzalcoatl
- Type changed from defect to enhancement
- Description modified (diff)
- 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.
comment:3 Changed 12 years ago by davidben
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.
comment:4 Changed 12 years ago by jdreed
I mean, is /usr/share/ca-certificates the "platform's native cert store"? Or can it be made to be?
comment:5 Changed 12 years ago by davidben
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.
comment:6 Changed 12 years ago by jdreed
- 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
comment:7 Changed 11 years ago by jdreed
Apparently Victor wrote chomium-config while I wasn't looking and it made it into -development?
comment:8 Changed 11 years ago by jdreed
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
Chromium caches in XDG_CACHE_HOME, so moving that to a local directory should be sufficient.