On Wed, Oct 25, 2017 at 1:05 PM, Alexander Bokovoy via FreeIPA-devel
<freeipa-devel@lists.fedorahosted.org> wrote:
> Hi,
> FYI.
> We are going to affected by this change, so we should start looking into
> possible breaks in Rawhide 'soon'.

If I get:

Upgrade/compatibility impact

Data will be migrated automatically.

In best case there won't be any breakage.  But we should be prepared
that some might appear.

> --
> / Alexander Bokovoy
> ---------- Forwarded message ----------
> From: Kai Engert <k...@kuix.de>
> To: Development discussions related to Fedora
> <de...@lists.fedoraproject.org>
> Cc:
> Bcc:
> Date: Wed, 25 Oct 2017 11:45:09 +0200
> Subject: NSS Default File Format SQL in Fedora 28
> 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:
>   https://bugzilla.redhat.com/show_bug.cgi?id=1496560
> 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
>   modifications.
>   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"
>   and
>     "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.)
> Thanks
> Kai
> ---------- Forwarded message ----------
> From: Jaroslav Reznik <jrez...@redhat.com>
> To: "discussions related to Fedora, Development"
> <de...@lists.fedoraproject.org>, devel-announce
> <devel-annou...@lists.fedoraproject.org>
> Cc:
> Bcc:
> Date: Thu, 6 Jul 2017 18:25:51 +0200
> Subject: F27 System Wide Change: NSS Default File Format SQL
> = System Wide Change: NSS Default File Format SQL =
> https://fedoraproject.org/wiki/Changes/NSSDefaultFileFormatSql
> 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
> storage.
> 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
> recovered.
> 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
> Thanks,
> Jaroslav
> _______________________________________________
> devel mailing list -- de...@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> _______________________________________________
> devel mailing list -- de...@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> _______________________________________________
> FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org

Petr Vobornik

Associate Manager, Engineering, Identity Management
Red Hat
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