On Thu, Jul 9, 2020 at 10:50 AM Daiki Ueno <ueno@xxxxxxxxxxxxxxxxx> wrote: > > Hello Igor, > > Sorry for the delay. > > Igor Raits <ignatenkobrain@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxx > >> > >> == 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! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
