Re: Fedora 33 Self-Contained Change proposal: NSS dbm support removal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



-----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: 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?

> 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-announce@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to 
> devel-announce-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-announce@xxxxxxxxxxxxxxxxxxxxxxx
- -- 
Igor Raits <ignatenkobrain@xxxxxxxxxxxxxxxxx>
-----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@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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux