Hello Igor, Sorry for the delay.
Igor Raits <ignatenkobr...@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: du...@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 -- email@example.com To unsubscribe send an email to devel-le...@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://firstname.lastname@example.org