← Back to team overview

desktop-packages team mailing list archive

[Bug 543183] Re: Updating system certificates requires rebuild

 

Launchpad has imported 12 comments from the remote bug at
https://bugzilla.mozilla.org/show_bug.cgi?id=449498.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2008-08-06T23:14:04+00:00 Kai Engert wrote:

Fedora has started to ship an NSS database in the OS global location
/etc/pki/nssdb, which contains system-wide certificates or security
modules that all applications should have access to.

I think the proposal is to open that additional database automatically
on NSS init time.

We'd like to do this at least on Linux, and maybe we should start with #ifdef'ed code.
We could add other platforms, too, if there is interest and a standardized location for this kind of database (with the initial version or at a later time).

Reply at: https://bugs.launchpad.net/firefox/+bug/543183/comments/0

------------------------------------------------------------------------
On 2010-06-15T19:23:04+00:00 dwmw2 wrote:

Created attachment 451345
xulrunner patch to make firefox use system nssdb

It shouldn't be an additional database; the application should open
sql:/etc/pki/nssdb _instead_ of its old database. The libnsssysinit.so
module automatically handles opening the user's own database in
~/.pki/nssdb as an 'overlay'.

With the NSS bugs fixed as described in
https://bugzilla.redhat.com/show_bug.cgi?id=603313 this works as
expected; merging the old DBM database from the profile directory into
the user's SQL database. If the system database isn't configured, then
it just uses the DBM database as before.

Reply at: https://bugs.launchpad.net/firefox/+bug/543183/comments/2

------------------------------------------------------------------------
On 2010-06-15T23:18:32+00:00 dwmw2 wrote:

Created attachment 451412
revised patch to try system db only on unix

Reply at: https://bugs.launchpad.net/firefox/+bug/543183/comments/3

------------------------------------------------------------------------
On 2010-06-16T14:59:52+00:00 Kai Engert wrote:

This bug was initially filed against the NSS component with the
expectation to

Reply at: https://bugs.launchpad.net/firefox/+bug/543183/comments/4

------------------------------------------------------------------------
On 2010-06-16T15:45:26+00:00 Nelson-bolyard wrote:

David, Are you requesting that this patch be reviewed and considered for 
inclusion?  Or is this merely a "work in progress"?  

If you believe this patch is ready for submission, please request that it 
be reviewed by kaie@xxxxxxx

Reply at: https://bugs.launchpad.net/firefox/+bug/543183/comments/5

------------------------------------------------------------------------
On 2010-06-16T16:52:37+00:00 dwmw2 wrote:

Comment on attachment 451412
revised patch to try system db only on unix

I think it's ready for inclusion. There are NSS bugs which need to be
fixed -- but this part only triggers if the system NSS DB is enabled
anyway; if it's not enabled you get the old behaviour.

Reply at: https://bugs.launchpad.net/firefox/+bug/543183/comments/6

------------------------------------------------------------------------
On 2010-06-16T17:09:02+00:00 Wan-Teh Chang wrote:

Comment on attachment 451412
revised patch to try system db only on unix

Bob Relyea is the best person to review this patch.

Bob, it'd be bad if an application had to read pkcs11.txt
directly and look for "library=libnsssysinit.so".

This should be done by the NSS initialization functions.
If we have a good error code that NSS initialization functions
can return to indicate a missing pkcs11.txt unambiguously,
an application can simply try initializing NSS with
"sql:/etc/pki/nssdb", and fall back on the home/profile
directory if it gets that error code.

Reply at: https://bugs.launchpad.net/firefox/+bug/543183/comments/7

------------------------------------------------------------------------
On 2010-06-16T17:17:12+00:00 dwmw2 wrote:

(In reply to comment #6)
> Bob, it'd be bad if an application had to read pkcs11.txt
> directly and look for "library=libnsssysinit.so".

Yeah, it sucks that we have to do this.

cf. https://bugzilla.mozilla.org/show_bug.cgi?id=490238#c37

I'd rather have NSS just do the right thing rather than returning an
error when we attempt to open sql:/etc/pki/nssdb r/w though.

Reply at: https://bugs.launchpad.net/firefox/+bug/543183/comments/8

------------------------------------------------------------------------
On 2010-07-30T23:02:51+00:00 Rrelyea wrote:

Comment on attachment 451412
revised patch to try system db only on unix

Way behind on my reviews. I'm OK with this patch with the following
caveats.

1) this is PSM code so Kai should have the final say since he'll have to support what goes in.
2) explicity checking for libnssysinit.so may fail in the future is we support some admin tool that replaces libnsssysinit with something that gets the nss configuration from some admin repository.

#1 is the more critical issue.

bob

Reply at: https://bugs.launchpad.net/firefox/+bug/543183/comments/9

------------------------------------------------------------------------
On 2010-07-31T08:30:15+00:00 dwmw2 wrote:

Having talked to people about GNOME keyring plans at GUADEC this week,
I'm a little bothered by your #2 too. I can envisage a situation where
we point at a GNOME-keyring PKCS#11 module directly from /etc/pki/nssdb,
instead of using libnsssysinit. (Although maybe we'd be more likely to
put that in the user's pkcs11.txt instead.)

Should we make it trigger if *any* module would be loaded by the
/etc/pki/nssdb/pkcs11.txt file, rather than just libnsssysinit.so ?

Reply at: https://bugs.launchpad.net/firefox/+bug/543183/comments/10

------------------------------------------------------------------------
On 2011-02-09T18:49:39+00:00 Kai Engert wrote:

This patch uses 
  NSS_InitWithMerge

Unless I missed something new, in my understanding, this may require
multiple master password prompts. This is necessary if the old profile
db uses a different password than the user's shared db in ~/.pki/nssdb

If this is true, in my understanding, we must use application assisted
merging.

This document lists a proposal of how this could be done:
https://wiki.mozilla.org/PSM:UIforSharedDB

If you agree with me that application assisted merging is necessary, I
believe this patch is r-

Reply at: https://bugs.launchpad.net/firefox/+bug/543183/comments/11

------------------------------------------------------------------------
On 2011-02-09T19:10:01+00:00 Kai Engert wrote:

*** Bug 620373 has been marked as a duplicate of this bug. ***

Reply at: https://bugs.launchpad.net/firefox/+bug/543183/comments/12


** Changed in: firefox
       Status: Unknown => Confirmed

** Changed in: firefox
   Importance: Unknown => Medium

** Bug watch added: Red Hat Bugzilla #603313
   https://bugzilla.redhat.com/show_bug.cgi?id=603313

** Bug watch added: Mozilla Bugzilla #490238
   https://bugzilla.mozilla.org/show_bug.cgi?id=490238

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/543183

Title:
  Updating system certificates requires rebuild

Status in The Mozilla Firefox Browser:
  Confirmed
Status in “firefox” package in Ubuntu:
  Triaged
Status in “firefox” package in Fedora:
  Unknown

Bug description:
  Binary package hint: firefox

  Hi,
  Updating the list of trusted root certificate authorities across all users of a system seems requires rebuilding a library. Non-root certificates may similarly be impacted.

  update-ca-certificates could be a mechanism  to update the root
  certificates used by firefox.

  On a corporate install of firefox, currently the only options to adding an internal root certificate authority are to:
     * Hack it into the user creation script to extract a pre-created profile, and update all the existing users profile directory. This bypasses the random profile directory creation.
     * Re-compile the shared library (.so) containing the root certificate authorities (extra maintenance for dealing with ubuntu package updates).
     * Have every user of the system go through a manual process of adding the root certificate (most users don't know how).
     * Use a plugin extension for firefox (do any exist?) that is automatically used by all users (can this be done?)
     * Have the root certificate signed at great expense by an external root certificate authority already included. CaCert integration would lower the cost but that seems far away, and is still an external authority. These root certificates also might be limited to a single domain (wildcard certificate?) or have other limitations ("low" expiry?, contractual restrictions...).

  It seems unlikely that Mozilla will move away from having the root
  certificates stored in the shared library as it would take some
  control away from them. The shared libary method makes it harder for
  malicious changes to be made, but only by adding the barier of
  recompilation and installation of a shared library.

  Thanks,

       Drew Daniels
  Resume: http://www.boxheap.net/ddaniels/resume.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/firefox/+bug/543183/+subscriptions