From Fedora Project Wiki
(Created page with "{{admon/important | Comments and Explanations | The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To re...")
 
(Add trackers)
 
(9 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{admon/important | Comments and Explanations | The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "view source" link.<br/> '''Copy the source to a ''new page'' before making changes!  DO NOT EDIT THIS TEMPLATE FOR YOUR CHANGE PROPOSAL.'''}}
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name.  This keeps all change proposals in the same namespace -->
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name.  This keeps all change proposals in the same namespace -->


= NSS DBM support removal =
= NSS dbm support removal =


== Summary ==
== 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 as default and the dbm backend has been considered deprecated ([[Changes/NSSDefaultFileFormatSql|NSS Default File Format SQL]]). This Change is about removing the support for the dbm backend entirely.
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 ==
== Owner ==
Line 25: Line 23:


== Current status ==
== Current status ==
[[Category:ChangePageIncomplete]]
[[Category:ChangeAcceptedF33]]
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
Line 44: Line 42:
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
-->
-->
* FESCo issue: <will be assigned by the Wrangler>
* FESCo issue: [https://pagure.io/fesco/issue/2415 #2415]
* Tracker bug: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1860953 #1860953]
* Release notes tracker: <will be assigned by the Wrangler>
* Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/540 #540]


== Detailed Description ==
== Detailed Description ==
Line 89: Line 87:


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
The impact should be limited, as long as the users always update from the previous version. That would ensure the existing databases are properly migrated.  
It is assured that the existing databases on the system are properly migrated, as long as they have been created or accessed with the default method on any supported Fedora releases (i.e., Fedora 31 or later). On the other hand, if a database is created explicitly as dbm, it needs to be converted before upgrading to F33. We will provide a script to check NSS databases on known locations and possibly run it during the package upgrade process.
 
Overall, as we consider the impact should be limited, we propose this as a Self Contained Change, rather than a System Wide Change.
 
Note: 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 ==
== How To Test ==
Line 135: Line 137:
* Contingency deadline: N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency deadline: N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Blocks release? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Blocks product? product <!-- Applicable for Changes that blocks specific product release/Fedora.next -->
* Blocks product? No <!-- Applicable for Changes that blocks specific product release/Fedora.next -->


== Documentation ==
== Documentation ==

Latest revision as of 14:32, 27 July 2020


NSS dbm support removal

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 (NSS Default File Format SQL). This Change is about removing the support for the dbm backend entirely.

Owner

Current status

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.

Feedback

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 (not a System Wide Change)
  • Policies and guidelines: N/A (not a System Wide Change)
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

It is assured that the existing databases on the system are properly migrated, as long as they have been created or accessed with the default method on any supported Fedora releases (i.e., Fedora 31 or later). On the other hand, if a database is created explicitly as dbm, it needs to be converted before upgrading to F33. We will provide a script to check NSS databases on known locations and possibly run it during the package upgrade process.

Overall, as we consider the impact should be limited, we propose this as a Self Contained Change, rather than a System Wide Change.

Note: 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 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
  • Blocks product? No

Documentation

N/A (not a System Wide Change)

Release Notes

Retrieved from "https://fedoraproject.org/w/index.php?title=Changes/NSSDBMRemoval&oldid=583439"