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.
Copy the source to a new page before making changes! DO NOT EDIT THIS TEMPLATE FOR YOUR CHANGE PROPOSAL.
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 as default and the dbm backend has been considered deprecated (NSS Default File Format SQL). This Change is about removing the support for the dbm backend entirely.
Owner
- Name: Daiki Ueno
- Email: dueno@redhat.com
Current status
- Targeted release: Fedora 33
- Last updated: 2020-06-10
- FESCo issue: <will be assigned by the Wrangler>
- Tracker bug: <will be assigned by the Wrangler>
- Release notes tracker: <will be assigned by the Wrangler>
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)
- Release engineering: #Releng issue number (a check of an impact with Release Engineering is needed)
- 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 are properly migrated.
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? N/A (not a System Wide Change), Yes/No
- Blocks product? product
Documentation
N/A (not a System Wide Change)