[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-devel-list
Subject:    Re: Fedora 33 Self-Contained Change proposal: NSS dbm support removal
From:       Daiki Ueno <ueno () fedoraproject ! org>
Date:       2020-07-09 14:50:12
Message-ID: 87blkokajf.fsf-ueno () fedoraproject ! org
[Download RAW message or body]

Hello Igor,

Sorry for the delay.

Igor Raits <ignatenkobrain@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@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.

Regards,
-- 
Daiki Ueno
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

[prev in list] [next in list] [prev in thread] [next in thread]