Re: Fedora 33 Self-Contained Change proposal: NSS dbm support removal
On Thu, Jul 9, 2020 at 10:50 AM Daiki Ueno wrote: > > Hello Igor, > > Sorry for the delay. > > Igor Raits 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. > 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@lists.fedoraproject.org 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://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Self-Contained Change proposal: NSS dbm support removal
Hello Igor, Sorry for the delay. Igor Raits 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 -- devel@lists.fedoraproject.org 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://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 Self-Contained Change proposal: NSS dbm support removal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 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? > In the discussion on the fedora-devel list, it was pointed that > pesign > package embedded the dbm format database. It has now been resolved in > [https://bugzilla.redhat.com/show_bug.cgi?id=1827902 bug 1827902]. > > == How To Test == > N/A (not a System Wide Change) > > == User Experience == > No user visible changes. > > == Dependencies == > N/A (not a System Wide Change) > > == Contingency Plan == > * Contingency mechanism: Revert the shipped configuration > * Contingency deadline: N/A (not a System Wide Change) > * Blocks release? No > > > > > > -- > Ben Cotton > He / Him / His > Senior Program Manager, Fedora & CentOS Stream > Red Hat > TZ=America/Indiana/Indianapolis > ___ > devel-announce mailing list -- devel-annou...@lists.fedoraproject.org > To unsubscribe send an email to > devel-announce-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://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl7n12oACgkQEV1auJxc Hh69AhAAqMcmdCbus8WJVDLeNcLl2o9jIMWGgcIzPcz0wrC70yGG46mkrlD47h/s c3ZuzhiCWi3xZ9NHOwkWpF46DJE9ac5/4bJjxv6doJNfRCoUIgdTYQpmXoYzWXqq mfQK8f2qD2PHaBkK+0Cq2z9TJ/7xigsPKxHPDbzwfjOV4IodTk/0RO6SxsdF6Y2V rOeaPVp+Lf+QRMKVGwpkRidMxwKxEsYN09MJc8yj9M+LL+lqepSzqB4oG1IevOlt 3xb1FG53W5WGe7SOEz4Gej3MVRt/YnZwsiIQD8ztEH8udp9+VBEEtyfVeNkcel0A t5Uq5sJccmWGARmua++4HC9lSPI92MbEITzePfBi8yPquXfhz7pBypKQ4922HarL 0Y4hj1D2hPCySXeFQ9sD0iccgcyew9a2Z/S//aCUIaMY2TTaqgPN2lo9MdD1MbFY r1YD24RA/ogSc+dyK01u354hsPvg0u/hfaZwmyBlXNLWmLu2nPHywhwrKbkPDppC G0dVqgHYSVVnFHuXmviuhWMyrUjiJJY7LDccXGrQEUoIAvU1nYw6HgWB7e/O8dwV OS+XOJDxlzdHolNxOXI+FUaL1r7MlbsAOAkFdS5lFBHSK81yU6BGn1KNPZ9K9z/T uFBZLsIr/T+/iT3pn+1N3DlLLXdAdw67N7MNh2mzwHWWIMv/6m4= =nJVu -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org 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://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
