On Thu, Jul 9, 2020 at 10:50 AM Daiki Ueno <ueno(a)fedoraproject.org> wrote:
Hello Igor,
Sorry for the delay.
Igor Raits <ignatenkobrain(a)fedoraproject.org> writes:
> On Mon, 2020-06-15 at 16:10 -0400, Ben Cotton wrote:
>>
https://fedoraproject.org/wiki/Changes/NSSDBMRemoval
>>
>> == Summary ==
>> Network Security Services (NSS) historically supports 2 different
>> database backends, based on SQLite and dbm. Since Fedora 28, the
>> SQLite backend has been used by default and the dbm backend has been
>> deprecated ([[Changes/NSSDefaultFileFormatSql|NSS Default File Format
>> SQL]]). This Change is about removing the support for the dbm backend
>> entirely.
>>
>> == Owner ==
>> * Name: [[User:ueno| Daiki Ueno]]
>> * Email: dueno(a)redhat.com
>>
>> == Detailed Description ==
>> Applications that use the NSS library often use a database for
>> storage
>> of keys, certificates and trust. NSS supports two different storage
>> formats, one is based on SQLite and another one is based on dbm
>> files.
>>
>> Today's default file format used by NSS, used when applications omit
>> the type parameter, is the SQLite file format, and the older dbm
>> format has been considered as deprecated since Fedora 28, because it
>> has several drawbacks such as lack of support for parallel access to
>> the storage.
>>
>> As the default change was made 2 years ago, and NSS provides a
>> transparent migration mechanism from the dbm format to the SQLite
>> format, the suggestion is to completely disable the dbm backend.
>>
>> == Benefit to Fedora ==
>> There are a few benefits:
>> * By disabling the dbm database, the size of the library binary will
>> be slightly smaller
>> * The NSS developers will be able to focus on the new file format
>>
>> == Scope ==
>> * Proposal owners:
>> A build time environment variable (NSS_DISABLE_DBM) needs to be set.
>>
>> * Other developers: N/A
>> * Policies and guidelines: N/A (not a System Wide Change)
>> * Trademark approval: N/A (not needed for this Change)
>>
>> == Upgrade/compatibility impact ==
>> The impact should be limited, as long as the users always update from
>> the previous version. That would ensure the existing databases on the
>> system are properly migrated. Therefore, we propose this as a Self
>> Contained Change, rather than a System Wide Change.
>
> Does it mean that people who upgrade from F31 to F33 will work just
> fine?
That should, as long as the NSS databases had been created or accessed
with the default method (that is SQLite) on F31. On the other hand, if
a database is created explicitly as dbm, it needs to be converted before
upgrading to F33.
If it is too worrisome, I'm willing to provide a script that checks if
the databases on the known locations are already converted.
I think it'd be worth doing this, and perhaps executing this as part
of upgrading.
--
真実はいつも一つ!/ Always, there's only one truth!