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 [email protected] 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 -- Mailing list: https://launchpad.net/~desktop-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
