#9486 Fedora Change Request: NSS CK_GCM_PARAMS change
Closed: Fixed 10 months ago by mohanboddu. Opened 11 months ago by rrelyea.

  • Describe the issue
    As part of the Fedora Change request process, there needs to be a releng evaluation of the change. Details of the change request is at: https://fedoraproject.org/wiki/Changes/NssGCMParams

  • When do you need this? (YYYY/MM/DD)
    Fedora 34 time frame

  • When is this no longer needed or useful? (YYYY/MM/DD)
    RHEL 9 branch

  • If we cannot complete your request, what is the impact?
    This is just an evaluation. I believe there is not release engineering impact for this change.

@rrelyea This seems like we need to consider this for a mass rebuild so that the packages will be runnable? But I am not sure how to pick an option from the 4 options you listed as part of mass rebuild.

Metadata Update from @mohanboddu:
- Issue tagged with: meeting

11 months ago

You don't need a mass rebuild. Once you've updated your package it should work even when the default switches. If you do a mass rebuild without an update, you will trigger the source incompatibility issue. If you don't rebuild, the old binary will continue to work.

I simple search for CK_GCM_PARAMS in your package will determine if anything needs to be done.

Picking among the 4 options:
option 1 is the easiest. It will be the same as not rebuilding the package, but you can make updates without triggering the source incompatibility issue. It's brittle because it depends on the state of the build options. Only use option 1 if you need to rebuild your package against older versions of nss (upstreams, for instance, may use option 1 so they don't add a dependency on nss 3.52).

option 2 is like option 1, but more robust. Your code isn't dependent on the state of the build options. It does add a dependence on nss 3.52.

option 3 is also pretty easy. it moves you to the new definition. It addes dependency on nss 3.52, but your package would work with external tokens which followed the actual spec.

option 4 is the preferred option, but it's a lot more extensive. You need to change your gcm code. Doing so has benefits (like you can add CHACHA_POLY support without a bunch of mechanism specific ifs, it uses the new PKCS #11 v3 AEAD interface if available, but falls back to the old V2 interface if the V3 interface is not available, the interface can handle all external tokens, knowing how to supply the appropriate structure if the interface rejects the new one.

Initially you'd probably want to pick options 1-3 and move to option 4 at your leisure.

@rrelyea AFAIU, it still needs building packages that buildrequires nss-devel. You could do this in a side tag, and you can use fedpkg request-side-tag to build the packages in a side tag.

Thanks for filing the ticket.

Metadata Update from @mohanboddu:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)
- Issue tagged with: change-noreleng, changes, f34

10 months ago

Login to comment on this ticket.