Fedora 34 System-Wide Change proposal: NSS CK_GCM_PARAMS change
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: rrel...@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:
Re: Fedora 34 System-Wide Change proposal: NSS CK_GCM_PARAMS change
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: rrel...@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
Re: Fedora 34 System-Wide Change proposal: NSS CK_GCM_PARAMS change
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: rrel...@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.
Re: Fedora 34 System-Wide Change proposal: NSS CK_GCM_PARAMS change
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/devel@lists.fedoraproject.org/thread/KSKKWWL4SXGYGOSGBWA2ZYLNAL3NPI7D/ Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
