Fedora 34 System-Wide Change proposal: NSS CK_GCM_PARAMS change

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/NssGCMParams

== Summary ==
Because of changes to the PKCS #11 spec in PKCS #11 v3.0, NSS needs to
change the definition of CK_GCM_PARAMS in a source incompatible way.
Upstream made this change in NSS 3.52.

== Owner ==
* Name: [[User:rrelyea| Bob Relyea]]
* Email: rrelyea(a)redhat.com


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

To solve this, the NSS 3.52 headers has both definitions:
CK_NSS_GCM_PARAMS is the original NSS definition and CK_GCM_PARAMS_V3
is the new (to NSS) definition. CK_GCM_PARAMS takes on one or the
other based on the definition of NSS_PKCS11_2_0_COMPAT.

The current NSS builds in fedora have changes the sense of this
#define to NSS_PKCS11_3_0_STRICT to get 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.

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,
but may break on newer tokens that use the new definition (same as the
previous behavior.

---------------------------------------------------------------

option 2

rename 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). 
Like option 2 it may break on newer tokens.

------------------------------------------------------------------

option 3

rename 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
run 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.
----------------------------------

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 these options by
fedora 34 or their rebuilt packages will fail at runtime.

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,
but may break on newer tokens that use the new definition (same as the
previous behavior.

---------------------------------------------------------------

option 2

rename 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). 
Like option 2 it may break on newer tokens.

------------------------------------------------------------------

option 3

rename 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
run 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.
----------------------------------

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.

* Release engineering: [https://pagure.io/releng/issue/9486 #Releng
issue number 9486]
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 ==
#. 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.


== 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.


== 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.


-- 
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis

[Zbigniew Jędrzejewski-Szmek]

On Thu, May 28, 2020 at 03:46:25PM -0400, Ben Cotton wrote:
>  https://fedoraproject.org/wiki/Changes/NssGCMParams
>  
>  == Summary ==
>  Because of changes to the PKCS #11 spec in PKCS #11 v3.0, NSS needs to
>  change the definition of CK_GCM_PARAMS in a source incompatible way.
>  Upstream made this change in NSS 3.52. 
When I'm reading this description, it feels like it was written by
somebody deep in the subject, but Change pages need to be accessible
to a general audience, even people who don't program in C. They should
be able to get the gist without having to absorb all the details.

It'd help if this summary mentioned that CK_GCM_PARAMS is a struct
definition and that a new field was added (if I got that right) and that
end programs need to adjust by changing how they do [what?].

>  == Owner ==
>  * Name: [[User:rrelyea| Bob Relyea]]
>  * Email: rrelyea(a)redhat.com
>  
>  
>  == Detailed Description ==
>  PKCS #11 2.40 had a mismatch between the SPEC and the released header
>  file for CK_GCM_PARAMS. The latter is controlling. We created or
>  header based on the former. In PKCS #11 v3.0 the reconciled this, but
>  it left us with. The new (to NSS) definition has a new field ulIvBits,
>  which must be set correctly. 
This part is very hard to grok. Is the capitalized "SPEC" an abbreviation?
One of the sentences ends mid-sentence. Also "must be set correctly"
by whom, how?

>  To solve this, the NSS 3.52 headers has both definitions:
>  CK_NSS_GCM_PARAMS is the original NSS definition and CK_GCM_PARAMS_V3
>  is the new (to NSS) definition. CK_GCM_PARAMS takes on one or the
>  other based on the definition of NSS_PKCS11_2_0_COMPAT.
>  
>  The current NSS builds in fedora have changes the sense of this
>  #define to NSS_PKCS11_3_0_STRICT to get 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.
>  
>  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,
>  but may break on newer tokens that use the new definition (same as the
>  previous behavior.
>  
>  ---------------------------------------------------------------
>  
>  option 2
>  
>  rename 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).
>  Like option 2 it may break on newer tokens. 
What does "rename" mean in this context? Based on the earlier text, I
thought CK_GCM_PARAMS was a structure...

>  ------------------------------------------------------------------
>  
>  option 3
>  
>  rename 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
>  run 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.
>  ----------------------------------
>  
>  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 these options by
>  fedora 34 or their rebuilt packages will fail at runtime. 
The text from above starts repeating here?

>  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,
>  but may break on newer tokens that use the new definition (same as the
>  previous behavior.
>  
>  ---------------------------------------------------------------
>  
>  option 2
>  
>  rename 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).
>  Like option 2 it may break on newer tokens.
>  
>  ------------------------------------------------------------------
>  
>  option 3
>  
>  rename 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
>  run 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.
>  ----------------------------------
>  
>  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.
>  
>  * Release engineering: [https://pagure.io/releng/issue/9486 #Releng
>  issue number 9486]
>  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 == 
This only applies to packages which use NSS. Maybe first specify a
repoquery line to figure out what packages may be affected because they
build-require nss.

If you could do this and the first step below and figure out how many
packages may be affected (along with a list of maintainers), we'd have
a much better idea of the scope of work.

>  #. 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.
>  
>  
>  == 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. 
We seem to have a chicken-and-egg problem here: solutions 2-4 require
the new nss, and non-updated packages will not run with the new nss. How do
envision the transition in rawhide? If new nss is pushed first, dependent
packages will be immediately broken.

It sounds like *all* the affected packages should be fixed and rebuilt
at the same time as the new nss is pushed.

[I see
https://src.fedoraproject.org/rpms/nss/c/614f823eb30b6ac0f0c6ea54ac9b5d26...
kept back the change for now.]

>  == 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. 
I don't think we should release with half of packages broken. I think
all packages need to be updated before beta.

Zbyszek

[Robert Relyea]

Oops, this reply was supposed to be a "reply list" rather than a
"reply".

I've incorporated most of your feedback into the Change page now.

Thanks.

bob

On 5/29/20 12:23 AM, Zbigniew Jędrzejewski-Szmek wrote:

>  On Thu, May 28, 2020 at 03:46:25PM -0400, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/NssGCMParams
> >
> > == Summary ==
> > Because of changes to the PKCS #11 spec in PKCS #11 v3.0, NSS needs to
> > change the definition of CK_GCM_PARAMS in a source incompatible way.
> > Upstream made this change in NSS 3.52.
>  When I'm reading this description, it feels like it was written by
>  somebody deep in the subject, but Change pages need to be accessible
>  to a general audience, even people who don't program in C. They should
>  be able to get the gist without having to absorb all the details. 
Thanks, If you
don't program in C, the change has no affect on you. It's 
a source level incompatibility, not a binary. I'll add that to the 
description.
>  It'd help if this summary mentioned that CK_GCM_PARAMS is a struct
>  definition and that a new field was added (if I got that right) and that
>  end programs need to adjust by changing how they do [what?]. 
Yup, how to adjust is
described below. I'm trying to keep the summary 
short.
> > == Owner ==
> > * Name: [[User:rrelyea| Bob Relyea]]
> > * Email: rrelyea(a)redhat.com
> >
> >
> > == Detailed Description ==
> > PKCS #11 2.40 had a mismatch between the SPEC and the released header
> > file for CK_GCM_PARAMS. The latter is controlling. We created or
> > header based on the former. In PKCS #11 v3.0 the reconciled this, but
> > it left us with. The new (to NSS) definition has a new field ulIvBits,
> > which must be set correctly.
>  This part is very hard to grok. Is the capitalized "SPEC" an 
>  abbreviation?
>  One of the sentences ends mid-sentence. Also "must be set correctly"
>  by whom, how? 
I need to fix some typos. "must be set correctly" is
described below.
> > To solve this, the NSS 3.52 headers has both definitions:
> > CK_NSS_GCM_PARAMS is the original NSS definition and CK_GCM_PARAMS_V3
> > is the new (to NSS) definition. CK_GCM_PARAMS takes on one or the
> > other based on the definition of NSS_PKCS11_2_0_COMPAT.
> >
> > The current NSS builds in fedora have changes the sense of this
> > #define to NSS_PKCS11_3_0_STRICT to get 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.
> >
> > 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,
> > but may break on newer tokens that use the new definition (same as the
> > previous behavior.
> >
> > ---------------------------------------------------------------
> >
> > option 2
> >
> > rename 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).
> > Like option 2 it may break on newer tokens.
>  What does "rename" mean in this context? Based on the earlier text, I
>  thought CK_GCM_PARAMS was a structure... 
It is. change your instances of
CK_GCM_PARAMS to CK_GCM_PARAMS_V3
> >
> ------------------------------------------------------------------
> >
> > option 3
> >
> > rename 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
> > run 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.
> > ----------------------------------
> >
> > 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 these options by
> > fedora 34 or their rebuilt packages will fail at runtime.
>  The text from above starts repeating here? 
I guess I could say "see
description".
> > 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,
> > but may break on newer tokens that use the new definition (same as the
> > previous behavior.
> >
> > ---------------------------------------------------------------
> >
> > option 2
> >
> > rename 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).
> > Like option 2 it may break on newer tokens.
> >
> > ------------------------------------------------------------------
> >
> > option 3
> >
> > rename 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
> > run 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.
> > ----------------------------------
> >
> > 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.
> >
> > * Release engineering: [https://pagure.io/releng/issue/9486 #Releng
> > issue number 9486]
> > 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 ==
>  This only applies to packages which use NSS. Maybe first specify a
>  repoquery line to figure out what packages may be affected because they
>  build-require nss.
>
>  If you could do this and the first step below and figure out how many
>  packages may be affected (along with a list of maintainers), we'd have
>  a much better idea of the scope of work.
>
> > #. 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.
> >
> >
> > == 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.
>  We seem to have a chicken-and-egg problem here: solutions 2-4 require
>  the new nss, and non-updated packages will not run with the new nss. 
>  How do
>  envision the transition in rawhide? If new nss is pushed first, dependent
>  packages will be immediately broken. 
No, nss 3.52 in fedora has been patched to
that the default is to use 
the old structure, and that version of nss is available on all supported 
versions of fedora currently. If you rebuild your package now, you will 
still get the old behavior by default. All the proposed fixes will work 
with the new 3.52 with patch. The testing section tells how you can make 
sure the new fixes will work when the patch is removed in fedora 34.
>  It sounds like *all* the affected packages should be fixed and rebuilt
>  at the same time as the new nss is pushed. 

No, see above.

>  [I see 
>
> https://src.fedoraproject.org/rpms/nss/c/614f823eb30b6ac0f0c6ea54ac9b5d26...
>
>
>  kept back the change for now.] 
Yes, this keeps the old default, but all the new
structures are 
available. All the options will work on both the patched and unpatched 
systems.
> > == 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.
>  I don't think we should release with half of packages broken. I think
>  all packages need to be updated before beta. 
I don't want to hold up the change because a package that no one cares 
about doesn't get in. This change gives packages a full release to get 
fixed.


bob

[Zbigniew Jędrzejewski-Szmek]

On Fri, May 29, 2020 at 08:56:26AM -0700, Robert Relyea wrote:
>  Oops, this reply was supposed to be a "reply list" rather
> than a "reply".
>  
>  I've incorporated most of your feedback into the Change page now. 
Thanks. Nevertheless, I still find the page hard to grok. I don't have
any specific comment — just the general reaction that after reading
the page 5 times I still don't know what the change is exactly and
what needs to be done in packages. (I guess I'm looking for something
like the recent announcement on nauty rebuilds [1]. Even without having
any idea what nauty is, I know what happened and what needs to be rebuilt.)
It's entirely possible that the problem is on my side, and the page is
perfectly clear to people working on NSS, so I'll shut up and let
others comment.

[1]
https://lists.fedoraproject.org/archives/list/[e-mail].o...

Zbyszek