From Fedora Project Wiki
(→‎Release Notes: https://pagure.io/fesco/issue/1688#comment-430734)
m (Fix typo)
 
(12 intermediate revisions by 4 users not shown)
Line 4: Line 4:


== Summary ==
== Summary ==
Currently, [http://www.openldap.org/ OpenLDAP] in Fedora is compiled with [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS NSS (aka MozNSS)] for cypto. OpenLDAP is going to be compiled with [https://www.openssl.org/ OpenSSL], instead.
Currently, [http://www.openldap.org/ OpenLDAP] in Fedora is compiled with [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS NSS (aka MozNSS)] for crypto. OpenLDAP is going to be compiled with [https://www.openssl.org/ OpenSSL], instead.


== Owner ==
== Owner ==
* Name: [[User:mhonek|Matus Honek]]
* Name: [[User:mhonek|Matus Honek]]
* Email: mhonek (at) redhat.com
* Email: mhonek (at) redhat.com
* Release notes owner: <!-- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> -->
* Release notes ticket: [https://pagure.io/fedora-docs/release-notes/issue/120 #120]<!-- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> -->
<!-- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
<!-- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
Line 19: Line 19:


== Current status ==
== Current status ==
* Targeted release: [[Releases/26 | Fedora 26 ]]  
* Targeted release: [[Releases/28 | Fedora 28 ]]  
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
Line 33: Line 33:
== Detailed Description ==
== Detailed Description ==
=== Insight ===
=== Insight ===
OpenLDAP in Fedora is has been compiled with NSS for crypto for several years now. Support layer for NSS was added back in 2008 but the OpenLDAP upstream ceased to keep it up to date since 2014. Reasons for keeping OpenLDAP compiled with NSS was to make it work with some other packages (esp. 389DS) seamlessly. Fixing and keeping downstream patches has become a burden, thus it was decided to switch to OpenSSL, instead.
OpenLDAP in Fedora has been compiled with NSS for crypto for several years now. Support layer for NSS was added back in 2008 but the OpenLDAP upstream ceased to keep it up to date since 2014. Reasons for keeping OpenLDAP compiled with NSS was to make it work with some other packages (esp. 389DS) seamlessly. Fixing and keeping downstream patches has become a burden, thus it was decided to switch to OpenSSL, instead.


=== Dependents ===
=== Dependents ===
Line 53: Line 53:


=== Schedule ===
=== Schedule ===
==== Fedora 26 ====
This is the proposed timeline that aims for clean adaptation by other components and users. In later Fedora releases the actual timelines may change.
 
==== Fedora 28 ====
* Land the OpenSSL-built OpenLDAP.
* Land the OpenSSL-built OpenLDAP.
* Include the [[#Interception code]].
* Include the [[#Interception code]].
Line 59: Line 61:
* Include a deprecation warning.
* Include a deprecation warning.


==== Fedora 27 ====
==== Fedora 29 ====
* Have <code>X_MOZNSS_COMPATIBILITY</code> implicitly set off by default.
* Have <code>X_MOZNSS_COMPATIBILITY</code> implicitly set off by default.


==== Fedora 28 ====
==== Fedora 30 ====
* Drop the [[#Interception code]] patching entirely.
* Drop the [[#Interception code]] patching entirely.
* Drop the deprecation warning.
* Drop the deprecation warning.
Line 88: Line 90:
** tear down the NSS context
** tear down the NSS context
* go on with OpenSSL only
* go on with OpenSSL only
Although all configuration and runtime cases should be handled, in case the [[#Interception code]] is not able to continue as expected it should fail cleanly with an appropriate error.


===== Considerations =====
===== Considerations =====
Line 119: Line 123:
<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->


* Release engineering: none.
* Release engineering: [https://pagure.io/releng/issue/6891]
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuid required?  If a rel-eng ticket exists, add a link here.  
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuid required?  If a rel-eng ticket exists, add a link here.  
Please work with releng prior to feature submission, and ensure that someone is on board to do any process development work and testing; don't just assume that a bullet point in a change puts someone else on the hook.-->
Please work with releng prior to feature submission, and ensure that someone is on board to do any process development work and testing; don't just assume that a bullet point in a change puts someone else on the hook.-->
Line 179: Line 183:
== Documentation ==
== Documentation ==
<!-- Is there upstream documentation on this change, or notes you have written yourself?  Link to that material here so other interested developers can get involved. -->
<!-- Is there upstream documentation on this change, or notes you have written yourself?  Link to that material here so other interested developers can get involved. -->
So far, this is the only document describing the change.
[[OpenLDAP-and-MozNSS-Compatibility-Layer]]


== Release Notes ==
== Release Notes ==
Line 188: Line 192:
-->
-->


[[Category:ChangePageIncomplete]]
[[Category:ChangeAcceptedF28]]
<!-- 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 -->

Latest revision as of 15:34, 3 April 2018


Switch OpenLDAP from NSS to OpenSSL

Summary

Currently, OpenLDAP in Fedora is compiled with NSS (aka MozNSS) for crypto. OpenLDAP is going to be compiled with OpenSSL, instead.

Owner

Current status

Detailed Description

Insight

OpenLDAP in Fedora has been compiled with NSS for crypto for several years now. Support layer for NSS was added back in 2008 but the OpenLDAP upstream ceased to keep it up to date since 2014. Reasons for keeping OpenLDAP compiled with NSS was to make it work with some other packages (esp. 389DS) seamlessly. Fixing and keeping downstream patches has become a burden, thus it was decided to switch to OpenSSL, instead.

Dependents

389DS

Upstream patch that mirrors certificates to PEM files so that OpenSSL-built OpenLDAP library may be used, is supported since version 389-ds-base-1.3.5.

See the design document.

FreeIPA

  • BuildRequires openldap-devel
  • Requires openldap-clients

SSSD

  • BuildRequires openldap-devel

other

  • dhcpd: BuildRequires openldap-devel
  • python-ldap: BuildRequires openldap-devel; uses OpenSSL for TLS, so maybe not a problem?

Schedule

This is the proposed timeline that aims for clean adaptation by other components and users. In later Fedora releases the actual timelines may change.

Fedora 28

  • Land the OpenSSL-built OpenLDAP.
  • Include the #Interception code.
  • Have X_MOZNSS_COMPATIBILITY implicitly set on by default.
  • Include a deprecation warning.

Fedora 29

  • Have X_MOZNSS_COMPATIBILITY implicitly set off by default.

Fedora 30

Implementation

The code handling possible NSS-specific configuration (#Interception code) should handle all possible use-cases (libldap, openldap-clients and openldap-servers packages). Briefly, the code should make usage of both, OpenSSL-specific and NSS-specific, configurations seamless with no more than setting the X_MOZNSS_COMPATIBILITY option on.

Build

Will build with ./configure --with-tls=openssl, dropping --with-tls=moznss. Also, NSS libs will be needed to be included so that the #Interception code works.

Interception code

Enabling

A yes/no options LDAP_OPT_X_MOZNSS_COMPATIBILITY (libldap), X_MOZNSS_COMPATIBILIY (ldap.conf, slapd.conf), and olcMozNSSCompatibility (slapd-config) may be used to explicitly set whether the #Interception code will be used.

Implementation

After parsing user options change these accordingly:

  • keep CACERT as set
  • if CACERTDIR is NSSDB then
    • if NSSDB is pin-protected then unlock it using KEY
    • extract all CA certs to ca.pem
    • extract all CA certs from (DEFAULT_)MOZNSS_DIR environment variable to (default_)moznss_dir.pem
    • extract user cert and key to user.pem
    • get the randomly pre-generated DH params from NSSDB and put it into DHParamFile
    • update options so that they work for OpenSSL
    • tear down the NSS context
  • go on with OpenSSL only

Although all configuration and runtime cases should be handled, in case the #Interception code is not able to continue as expected it should fail cleanly with an appropriate error.

Considerations
PEM files location

We should keep the NSSDB in place, while creating a directory with the same owner and permissions for storing the extracted PEM files. If the directory cannot be created, we should temporarily put these to a tempdir (in /tmp).

CRLCheck and CRLFile options

NSS uses CRLFILE option only, whereas OpenSSL uses CRLCHECK bool. There is no feasible way to be backward-compatible.

NSS still used

Even though temporarily, NSS library is still used possibly causing some (although few) troubles.

Pitfalls

Downgrade

Will not be supported automatically. We should provide steps how to revert to NSSDB having OpenSSL-like configuration in place.

Mixed configuration options have undefined behaviour

If both, OpenSSL-like and NSS-like, configurations are used for various configuration parameters at the same time then the behaviour SHOULD not be destructive but it is undefined.


Benefit to Fedora

Support from upstream -- currently, most bugs are related to MozNSS and upstream refuses to bother with our TLS or PKI related issues as they do not support MozNSS anymore.

Scope

  • Other developers: ensure usage of OpenSSL-like TLS configuration based on the #Schedule.
  • Policies and guidelines: none.
  • Trademark approval: none.

Upgrade/compatibility impact

No issues should occur in the first phase (see #Schedule).

How To Test

  • This change is not hardware-specific.
  • This changes the libldap library, thus all packages of the OpenLDAP component are affected, as well as all the other packages that Require or BuildRequire some of OpenLDAP packages.
  • Testing
    1. Sanity testing should be done for both MozNSS-NSSDB-like and OpenSSL-like configuration and for each of the following specifics:
      • Basic self-signed CA cert and user cert/key
      • Self-signed CA cert chain
    2. Dependent packages' tests

All configurations should work as expected, no regression should occur.

User Experience

No changes should occur. However, from the third phase (see #Schedule) on users will not be able to use NSSDB.

Dependencies

This change does not depend on any other change.

Contingency Plan

  • Contingency mechanism: revert the patches implementing the change. No external changes would be required.
  • Contingency deadline: beta freeze.
  • Blocks release? No.
  • Blocks product? No.

Documentation

OpenLDAP-and-MozNSS-Compatibility-Layer

Release Notes