Ticket #1185 (new enhancement)

Opened 9 years ago

Last modified 7 years ago

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:1 Changed 9 years ago by davidben

Chromium caches in XDG_CACHE_HOME, so moving that to a local directory should be sufficient.

comment:2 Changed 9 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 9 years ago by davidben

Some of these things may be useful.


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 8 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 8 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.


This bug seems relevant.


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 8 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 7 years ago by jdreed

Apparently Victor wrote chomium-config while I wasn't looking and it made it into -development?

comment:8 Changed 7 years ago by jdreed

comment:9 Changed 7 years ago by jdreed

Victor's chromium-config (enabling idp.mit.edu for GSSAPI) went to production today.

Note: See TracTickets for help on using tickets.