Changes

Jump to: navigation, search

NSS Shared DB

64 bytes removed, 17:03, 14 August 2007
→‎Update complications.
==--=Update complications.=====
Updated complications only affect Type A applications. In order to merge a
exception A. Application needs to decide what happens if the legacy password
is not supplied. Application can choose to:
1) # continue to use the legacy DB and try to update later. 2) # force NSS to mark legacy DB to be updated without actually updating the legacy DB (throwing away everything in the legacy DB). 3) # force NSS to update those objects it can from the legacy DB, throwing
away private keys and saved passwords.
exception B. Applications needs to decide what happens if the new shared DB
password is not supplied. Application can choose to:
1) # continue to use the legacy DB and try to update later. 2) # force NSS to mark legacy DB to be updated without actually updating the legacy DB (throwing away everything in the legacy DB). 3) # force NSS to update those objects it can from the legacy DB, throwing away private keys and saved passwords, and trust information from the legacy DB. 4) # force NSS to reset the shared database password, throwing away private keys and saved passwords, and trust information from rom the shared DB.
NOTE: Since we are potentially dealing with 2 different passwords, The
application needs to be clear to the user which password it needs.
===== Merge Conflicts (Mode 3A only)=====
When merging databases in, it's possible (even likely), that the shared
the merge is a simple matter of identifying duplicates and not updating them.
In the case of trust attributes, however, there are a number of choices:
1) # don't update duplicate trust (shared database copy wins). 2) # overwrite trust from the legacy DB (legacy db copy wins). 3) # calculate the least common denominator trust between them (take the least trusted values). (turning off trust wins). 4) # calculate the most common demonimnator trust between the two (turning on trust wins). 
From the user perspective, each of these choices means:
1) # after the update the application that just updated may trust certs that
it had previously marked untrusted, or certs that it has marked trusted are
no longer trusted.
2) # after the update other applications that share the database may trust
certs they had previously marked untrusted, or certs that they had marked as
trusted are no longer trusted.
3) # after the update all apps may find the certs that they marked trust are
no longer trusted.
4) # after the update all apps may find that they trust certs that have
previously been marked untrusted.
passwords, the merged database will have to have a
===== Mozilla Applications.=====
Mozilla applications are Mode 3A applications. In fact, for all intents and
(any of the below apply):
1) # The Mozilla app is starting as a fresh instance.2) # The Mozilla app has already been updated.3) # The shared database does not have a master password set and The legacy database for Mozilla app does a master password set.
These are the most common cases.
===== Profile issues.=====
Mozilla apps can create more than one profile. Developers use this capability
1) # Allow profiles to be marked with 'private key/cert DB's. This will change
The Mozilla app from a Mode 3A app to a Mode 2A app. This will return
developers to their previous semantic if they want, while allowing them to
require UI changes to the profile manager, and it will require action on the
part of the developer to get back to the old semantic.
 2) # Treat only the default profile as Mode 3A and all other profiles as Mode 2A.
This will allow profile separation to operate as is today with no changes. It
does mean, however, that only default profiles will share keys with
appllication.
 3) # Provide the checkbox in option 1, but make it default as in option 2.
I think option 3 probably provides the best solution for all worlds.
Relyea
439
edits
Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/65398"

Navigation menu