From Fedora Project Wiki
mNo edit summary
(Add trackers)
 
(22 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.'''}}


<!-- Self Contained or System Wide Change Proposal?
= NSS CK_GCM_PARAMS change =
Use this guide to determine to which category your proposed change belongs to.
 
Self Contained Changes are:
* changes to isolated/leaf package without the impact on other packages/rest of the distribution
* limited scope changes without the impact on other packages/rest of the distribution
* coordinated effort within SIG with limited impact outside SIG functional area, accepted by the SIG
 
System Wide Changes are:
* changes that does not fit Self Contained Changes category touching
* changes that require coordination within the distribution (for example mass rebuilds, release engineering or other teams effort etc.)
* changing system defaults
 
For Self Contained Changes, sections marked as "REQUIRED FOR SYSTEM WIDE CHANGES" are OPTIONAL but FESCo/Wrangler can request more details (especially in case the change proposal category is improper or updated to System Wide category). For System Wide Changes all fields on this form are required for FESCo acceptance (when applies). 
 
We request that you maintain the same order of sections so that all of the change proposal pages are uniform.
-->
 
<!-- 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 -->
 
= Change Proposal Name <!-- The name of your change proposal --> =


== Summary ==
== Summary ==
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release.  
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release.  
Note that motivation for the change should be in the Benefit to Fedora section below, and this part should answer the question "What?" rather than "Why?". -->
Note that motivation for the change should be in the Benefit to Fedora section below, and this part should answer the question "What?" rather than "Why?". -->
Because of changes to the PKCS #11 spec in PKCS #11 v3.0, NSS needs to change the definition of  the CK_GCM_PARAMS structure in a source incompatible way. Upstream made this change in NSS 3.52. This change does not affect the ABI. Old programs compiled with older versions of NSS will still work. Only packages that use NSS and directly call AES GCM are affected.


== Owner ==
== Owner ==
Line 32: Line 12:
This should link to your home wiki page so we know who you are.  
This should link to your home wiki page so we know who you are.  
-->
-->
* Name: [[User:FASAcountName| Your Name]]
* Name: [[User:rrelyea| Bob Relyea]]
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
* Email: <your email address so we can contact you, invite you to meetings, etc. Please provide your Bugzilla email address if it is different from your email in FAS>
* Email: rrelyea@redhat.com
<!--- 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 44: Line 24:


== Current status ==
== Current status ==
[[Category:ChangePageIncomplete]]
[[Category:ChangeAcceptedF34]]
<!-- 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 51: Line 31:


<!-- Select proper category, default is Self Contained Change -->
<!-- Select proper category, default is Self Contained Change -->
[[Category:SelfContainedChange]]
<!-- [[Category:SelfContainedChange]] -->
<!-- [[Category:SystemWideChange]] -->
[[Category:SystemWideChange]]


* Targeted release: [[Releases/<number> | Fedora <number> ]]  
* Targeted release: [[Releases/34 | Fedora 34 ]]  
* 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 63: Line 43:
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/2400 #2400]
* Tracker bug: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1866878 #1866878]
* Release notes tracker: <will be assigned by the Wrangler>
* Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/544 #544]


== Detailed Description ==
== Detailed Description ==


<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
PKCS #11 2.40 had a mismatch between the spec and the released header file for the CK_GCM_PARAMS structure. The latter is controlling. We created our header based on the former. In PKCS #11 v3.0 the reconciled this, but it left us with and incompatible header. The new (to NSS) definition has a new field ulIvBits, which must be set correctly (see below).
To solve this, the NSS 3.52 headers has definitions for both structures: CK_NSS_GCM_PARAMS is the original NSS definition and CK_GCM_PARAMS_V3 is the new (to NSS) definition matching the current spec. CK_GCM_PARAMS will take on the definition of CK_GCM_PARAM_V3 by default, and CK_NSS_GCM_PARAMS if the code is compiled with NSS_PKCS11_2_0_COMPAT defined.
The current NSS builds in fedora have changes the sense of this #define so defining NSS_PKCS11_3_0_STRICT to gets the new behavior, and keep the old behavior by default. NSS builds will automatically switch back to the upstream default in Fedora 34. None of the changes below actually requires setting the NSS_PKCS11_3_STRICT define, though doing so can test that all but option 1 is functioning. These changes can be made in the current fedora as long as you have NSS 3.52.
Applications can fix this the following ways:
option 1
#define NSS_PKCS11_2_0_COMPAT 1
or compile with -DNSS_PKCS11_2_0_COMPAT
your app will compile and run using current and older versions of NSS (no need for nss 3.52), but may break on newer tokens that use the new definition (same as the previous behavior). Do this if your packages needs to compile in enviroments that have old versions of nss.
---------------------------------------------------------------
option 2
rename all occurances of CK_GCM_PARAMS to CK_NSS_GCM_PARAMS (this will now require nss >= 3.52 to compile, but won't change based on NSS_PKCS11_2_0_COMPAT or NSS_PKCS11_3_0_STRICT). Like option 1 it may break on newer tokens.
------------------------------------------------------------------
option 3
rename all occurances of CK_GCM_PARAMS to CK_GCM_PARAMS_V3 and set ulIvBits to ulIvLen*8.
This will require nss >= 3.52 to compile and to run. Should run on all new tokens. May break on older tokens.
-----------------------------------------------------------------
option 4
Move to PK11_AEADOp  interface, which all requires nss >= 3.52 to compile and run,  but it's less surprising and the dependency will be picked up automatically because you are using a new for 3.52 interface, so it will continue to work against all tokens.
----------------------------------
Option 4 is the preferred solution. It takes advantage the the PKCS #11 v3 interface for  AES_GCM while removing any PCKS #11 param structure dependency in the application. It also handles backward compatibility on older tokens and automatically detects which flavor of data structure is supported. It also would help with applications that support two or more of AES_GCM, AES_CCM, and CHACHA_POLY.


== Benefit to Fedora ==
== Benefit to Fedora ==
Line 100: Line 118:
     https://fedoraproject.org/wiki/Changes/perl5.26 (major upgrade to a popular software stack, visible to users of that stack)
     https://fedoraproject.org/wiki/Changes/perl5.26 (major upgrade to a popular software stack, visible to users of that stack)
-->
-->
This change will keep fedora with the NSS upstream as well as make Fedora compliant with the official OASIS PKCS #11 spec.


== Scope ==
== Scope ==
Line 105: Line 125:
<!-- What work do the feature owners 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 the feature owners 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?-->


* Other developers: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
NSS 3.52 has already had builds made with the reverse sense. NSS will need to be rebuilt at the start of Fedora 34.
 
* Other developers: <!-- REQUIRED FOR SYSTEM WIDE 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?-->
<!-- 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: [https://pagure.io/releng/issues #Releng issue number] (a check of an impact with Release Engineering is needed) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
Developers need to choose one of the options listed in the description by fedora 34 or their rebuilt packages will fail at runtime.
 
 
* Release engineering: [https://pagure.io/releng/issue/9486 #Releng issue number 9486]  
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.  
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.  
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
I believe there is no additional release engineering requirements for this bug. Only packages which use CK_AES_GCM_PARAMS need action and the action can happen outside the release process.


* Policies and guidelines: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Policies and guidelines: <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Do the packaging guidelines or other documents need to be updated for this feature?  If so, does it need to happen before or after the implementation is done?  If a FPC ticket exists, add a link here. -->
<!-- Do the packaging guidelines or other documents need to be updated for this feature?  If so, does it need to happen before or after the implementation is done?  If a FPC ticket exists, add a link here. -->
There isn't any policy or guideline changes needed for this change.


* Trademark approval: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
Line 122: Line 149:


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A (not a System Wide Change)  
There is no upgrade impact. There will be a source level incompatibility on rebuild at fedora 34. This change is to allow a transition in fedora 33 where source code can be updated in ways that work in both fedora 33 and fedora 34 after recompile. There are no binary compatibility issues (old applications compiled with the old version of nss will continue to work).


== How To Test ==
== How To Test ==
Line 138: Line 165:
3. What are the expected results of those actions?
3. What are the expected results of those actions?
-->
-->
#. Grep for CK_AES_GCM_PARAMS in our source tree. If it does not appear, no further action is needed.
#. If you choose options 2-4, you can do a normal test build and run your normal tests against any version of nss > 3.52
#. If you think you don't need to make a change, compile your package with -DNSS_PKCS11_3_0_STRICT and run your normal tests. If everything works should should not need further action.
#. option 1 would require building NSS without the patch and then rebuilding with your package. Only use option 1 if you need to build your package against older versions of nss.
NOTE: The effect of not changing will create a runtime issue where your AES_GCM call will fail after recompiling.


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A (not a System Wide Change)


== User Experience ==
== User Experience ==
Line 153: Line 184:
  - Green has been scientifically proven to be the most relaxing color. The move to a default background color of green with green text will result in Fedora users being the most relaxed users of any operating system.
  - Green has been scientifically proven to be the most relaxing color. The move to a default background color of green with green text will result in Fedora users being the most relaxed users of any operating system.
-->
-->
Users who don't build their own packages will see no issues. Users that build their own packages and use classic NSS AES_GCM will see runtime failures after a rebuild unless they update their packages.


== Dependencies ==
== Dependencies ==
<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this change depends?  In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like the kernel (if this is not a kernel change)? -->
<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this change depends?  In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like the kernel (if this is not a kernel change)? -->
nss-3.52 or greater. nss-3.52 is now available in all supported versions of fedora.


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A (not a System Wide Change)


== Contingency Plan ==
== Contingency Plan ==


<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
* Contingency mechanism: (What to do?  Who will do it?) N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency mechanism:
If critical packages are not updated, the NSS team can turn off the automatic move in fedora 34. If non-critical packages do not update, then they will just fail on the first rebuild in fedora 34. Libreswan is the only critical package we know of at this time that is affected. Upstream already has the appropriate changes.
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
<!-- When is the last time the contingency mechanism can be put in place?  This will typically be the beta freeze. -->
* Contingency deadline: N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency deadline: beta freeze
<!-- 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? Yes, but only for critical packages.
* Blocks product? product <!-- Applicable for Changes that blocks specific product release/Fedora.next -->
 


== Documentation ==
== Documentation ==
Line 174: Line 207:


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A (not a System Wide Change)
Description contains the notes that upstream is working on, modified for fedora. I'll include links once upstream has released them.


== Release Notes ==
== Release Notes ==
Line 182: Line 215:
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze.  
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze.  
-->
-->
Replicate the description in the release notes of fedora 33 and fedora 34. Users can make their own changes in fedora 33 before fedora 34 is released.

Latest revision as of 17:15, 6 August 2020

NSS CK_GCM_PARAMS change

Summary

Because of changes to the PKCS #11 spec in PKCS #11 v3.0, NSS needs to change the definition of the CK_GCM_PARAMS structure in a source incompatible way. Upstream made this change in NSS 3.52. This change does not affect the ABI. Old programs compiled with older versions of NSS will still work. Only packages that use NSS and directly call AES GCM are affected.

Owner

Current status

Detailed Description

PKCS #11 2.40 had a mismatch between the spec and the released header file for the CK_GCM_PARAMS structure. The latter is controlling. We created our header based on the former. In PKCS #11 v3.0 the reconciled this, but it left us with and incompatible header. The new (to NSS) definition has a new field ulIvBits, which must be set correctly (see below).

To solve this, the NSS 3.52 headers has definitions for both structures: CK_NSS_GCM_PARAMS is the original NSS definition and CK_GCM_PARAMS_V3 is the new (to NSS) definition matching the current spec. CK_GCM_PARAMS will take on the definition of CK_GCM_PARAM_V3 by default, and CK_NSS_GCM_PARAMS if the code is compiled with NSS_PKCS11_2_0_COMPAT defined.

The current NSS builds in fedora have changes the sense of this #define so defining NSS_PKCS11_3_0_STRICT to gets the new behavior, and keep the old behavior by default. NSS builds will automatically switch back to the upstream default in Fedora 34. None of the changes below actually requires setting the NSS_PKCS11_3_STRICT define, though doing so can test that all but option 1 is functioning. These changes can be made in the current fedora as long as you have NSS 3.52.

Applications can fix this the following ways:

option 1 

#define NSS_PKCS11_2_0_COMPAT 1

or compile with -DNSS_PKCS11_2_0_COMPAT

your app will compile and run using current and older versions of NSS (no need for nss 3.52), but may break on newer tokens that use the new definition (same as the previous behavior). Do this if your packages needs to compile in enviroments that have old versions of nss.

option 2

rename all occurances of CK_GCM_PARAMS to CK_NSS_GCM_PARAMS (this will now require nss >= 3.52 to compile, but won't change based on NSS_PKCS11_2_0_COMPAT or NSS_PKCS11_3_0_STRICT). Like option 1 it may break on newer tokens.

option 3

rename all occurances of CK_GCM_PARAMS to CK_GCM_PARAMS_V3 and set ulIvBits to ulIvLen*8.

This will require nss >= 3.52 to compile and to run. Should run on all new tokens. May break on older tokens.

option 4

Move to PK11_AEADOp interface, which all requires nss >= 3.52 to compile and run, but it's less surprising and the dependency will be picked up automatically because you are using a new for 3.52 interface, so it will continue to work against all tokens.

Option 4 is the preferred solution. It takes advantage the the PKCS #11 v3 interface for AES_GCM while removing any PCKS #11 param structure dependency in the application. It also handles backward compatibility on older tokens and automatically detects which flavor of data structure is supported. It also would help with applications that support two or more of AES_GCM, AES_CCM, and CHACHA_POLY.

Benefit to Fedora

This change will keep fedora with the NSS upstream as well as make Fedora compliant with the official OASIS PKCS #11 spec.

Scope

  • Proposal owners:

NSS 3.52 has already had builds made with the reverse sense. NSS will need to be rebuilt at the start of Fedora 34.

  • Other developers:

Developers need to choose one of the options listed in the description by fedora 34 or their rebuilt packages will fail at runtime.


I believe there is no additional release engineering requirements for this bug. Only packages which use CK_AES_GCM_PARAMS need action and the action can happen outside the release process.

  • Policies and guidelines:

There isn't any policy or guideline changes needed for this change.

  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

There is no upgrade impact. There will be a source level incompatibility on rebuild at fedora 34. This change is to allow a transition in fedora 33 where source code can be updated in ways that work in both fedora 33 and fedora 34 after recompile. There are no binary compatibility issues (old applications compiled with the old version of nss will continue to work).

How To Test

  1. . Grep for CK_AES_GCM_PARAMS in our source tree. If it does not appear, no further action is needed.
  2. . If you choose options 2-4, you can do a normal test build and run your normal tests against any version of nss > 3.52
  3. . If you think you don't need to make a change, compile your package with -DNSS_PKCS11_3_0_STRICT and run your normal tests. If everything works should should not need further action.
  4. . option 1 would require building NSS without the patch and then rebuilding with your package. Only use option 1 if you need to build your package against older versions of nss.

NOTE: The effect of not changing will create a runtime issue where your AES_GCM call will fail after recompiling.


User Experience

Users who don't build their own packages will see no issues. Users that build their own packages and use classic NSS AES_GCM will see runtime failures after a rebuild unless they update their packages.

Dependencies

nss-3.52 or greater. nss-3.52 is now available in all supported versions of fedora.


Contingency Plan

  • Contingency mechanism:

If critical packages are not updated, the NSS team can turn off the automatic move in fedora 34. If non-critical packages do not update, then they will just fail on the first rebuild in fedora 34. Libreswan is the only critical package we know of at this time that is affected. Upstream already has the appropriate changes.

  • Contingency deadline: beta freeze
  • Blocks release? Yes, but only for critical packages.


Documentation

Description contains the notes that upstream is working on, modified for fedora. I'll include links once upstream has released them.

Release Notes

Replicate the description in the release notes of fedora 33 and fedora 34. Users can make their own changes in fedora 33 before fedora 34 is released.

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