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

[Ben Cotton]

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(a)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.

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

[Igor Raits]

-----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(a)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-announce(a)lists.fedoraproject.org
>  To unsubscribe send an email to 
>  devel-announce-leave(a)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/[e-mail]...
- -- 
Igor Raits <ignatenkobrain(a)fedoraproject.org&gt;
> -----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-----

[Daiki Ueno]

Hello Igor,

Sorry for the delay.

Igor Raits <ignatenkobrain(a)fedoraproject.org&gt; 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(a)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

[Neal Gompa]

On Thu, Jul 9, 2020 at 10:50 AM Daiki Ueno <ueno(a)fedoraproject.org&gt; wrote:
>  Hello Igor,
>
>  Sorry for the delay.
>
>  Igor Raits <ignatenkobrain(a)fedoraproject.org&gt; 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(a)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!