We are going to affected by this change, so we should start looking into
possible breaks in Rawhide 'soon'.

/ Alexander Bokovoy
--- Begin Message ---
TL;DR: The change originally planned for Fedora 27 will now be done for
Rawhide Fedora 28, probably tomorrow.

We had previously announced to change the NSS crypto library to use the
new sql file format by default. Please see the attached message for the
technical details.

Because of blocker bugs, it wasn't done for Fedora 27. During the past
months the known bugs in NSS were fixed, and the Firefox/Mozilla code
was improved. I think now we're ready to make the change for Rawhide.

If I understand correctly, at the current time of the development phase
of Rawhide Fedora 28, it isn't necessary to go through a formal process
to make this change.

The new tracking bug is:

The following is noteworthy, when using NSS with the sql file format:

- Performance is slightly reduced. The old dbm storage didn't use any
  locking mechanism, and therefore it was easy to get corrupted storage
  when accessing the files in parallel by more than one application.
  The new sqlite storage can safely be used by multiple applications
  in parallel, but this has a performance cost.

- NSS databases (old and new) can be protected with a password.
  Previously, some modification operations could be performed without
  unlocking the database.
  When using the new sql storage, NSS more strictly requires the
  user to log in to (unlock) the database prior to performing
  For example, when modifying the trust settings of a CA certificate
  with certutil, it will be necessary to provide the database password.

- With sql databases, NSS is more strict with half-initialized
  databases. In the early years of the Netscape/Mozilla era,
  in order to support some application/browser level functionality,
  it had been necessary to distinguish between
    "half initialized state:
     no password ever set on the database, not even an empty password"
    "fully initialized state:
     password set on the database, even if it's just the empty string".
  We believe this state is no longer required,
  certutil and modutil no longer create half-initialized databases.
  Until recently, NSS databases created by Firefox/Thunderbird etc.
  were still in this half-initialized state.
  There might be other applications that did this.
  When using a database in the half-initialized state, some
  database operations could fail, with similar symptons as not having
  logged in to the database, even after databases are (automatically)
  migrated to the sql format (the half-initialized state is kept).
  When experiencing such issues, it will be necessary to explicitly
  set a password on the database, even if it's just the empty string.

In order to adjust for these properties, Firefox has been changed to
always initialize NSS databases with an empty password.

In addition, Firefox has been changed to prompt the user for the NSS
database password (Firefox calls it the master password) if necessary,
prior to e.g. trust database modificiations.

These recent changes will be contained in NSS 3.34, Firefox 58 and
Thunderbird 59, which aren't released yet.

In order to allow us testing the new sql database file format with
Fedora Rawhide as soon as possible, the changes have been backported to
the versions currently used in Rawhide: NSS 3.33, Firefox 57 beta,
Thunderbird 52.4. The packages were built yesterday.

If other applications based on Mozilla Gecko, e.g. like Iceowl or
Icecat, would like to avoid that users run into these potential
failures, they could pick up the same backported patches. Please look at
the commits for Firefox and Thunderbird to find them, or see the
dependency list of bug 1496560.

Please let us know if you experience problems. (Ideally, please file a
bug against the "nss" component and CC kengert@rh, hkario@rh,
rrelyea@rh, dueno@rh.)


--- Begin Message ---
= System Wide Change: NSS Default File Format SQL =

Change owner(s):
* Kai Engert <k...@redhat.com>

Change the NSS library default to use the sqlite based data storage,
when applications don't specify their preferred storage file format.

== Detailed Description ==

Applications that use the NSS library often use a database for storage
of keys, certificates and trust. NSS supports two different file
formats, one called DBM (based on berkeley DB files) and another one
called SQL (based on sqlite DB files).

Today's default file format used by NSS, used when applications omit
the type parameter, is the older DBM file format, which forbids
parallel access to the storage. The suggestion is to change the
default file format to SQL, which allows parallel access to the

Applications, or users using the NSS command line utilities, often
provide the database storage location using a simple directory path
parameter. Some might not be aware, or forget, that the parameter can
be prefixed with a type modifier, either "dbm:" or "sql:".

As a result, when not providing this parameter, the file format used
will be the fragile DBM file format. This is particuarly problematic,
if a user attempts to modify the NSS storage using command line tools,
while another process, such as a daemon, is running concurrently,
which also accesses the same database in the DBM file format. This
often results in corrupted database storage, which cannot be

By changing the default, all applications that currently use the DBM
file format, will automatically be migrated to the SQL file format.
NSS has the ability to discover if a storage location (a directory)
contains the DBM file format. If configured to use the modern SQL
format, NSS will automatically perform a one-time conversion from the
DBM to the SQL format.

The same applies to the NSS command line utilities. If the NSS library
default is changed to SQL, the NSS tools will also trigger the
one-time conversion, or access the already converted files.

== Scope ==

* Proposal owners:

A small downstream patch needs to be applied to the NSS library
package, which changes the library default.

* Other developers:

It's up to developers of NSS applications, if they accept the new
default and an automatic conversion, or if they prefer to continue to
use the classic DBM storage format. Although not recommended,
developers can easily do so, by adding a "dbm:" prefix to the storage
parameter they provide to NSS at NSS library initialization time.

* Release engineering: [1]

No help should be necessary. No mass rebuild necessary.

* Policies and guidelines: N/A

* Trademark approval: N/A

[1] https://pagure.io/releng/issue/6883

devel mailing list -- de...@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

--- End Message ---
devel mailing list -- de...@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

--- End Message ---
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

Reply via email to