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.
Metadata Update from @bcotton: - Issue tagged with: F34
@rrelyea would it be possible for you to analyse which packages would be affected?
I am not subject matter expert, but given that this is submitted very early (hey, this is first change for F34!), I am +1 so that we can make everything work fine or revert long before the release.
Note that you will need to wait for branching to happen before pushing the change to the git.
If you have a command I can type that would give all the packages that require nss-devel to build, then I could do a grep for CK_GCM_PARAMS in the source trees for those packages. Only packages with a hit could possibly require patching.
Any NSS changes has already been checked in. The Upstream default is to map CK_GCM_PARAMS to the new structure. The current rawhide builds, f32 builds and f31 builds have a patch the reverses this default. The spec conditionally includes the patch if the fedora build is < 34, so all that is needed after the branch is a rebuild. Also packages can patch their builds in rawhide and f31 or f32. All the suggested fixes work independently of whether or not the default definition patch is included or not.
+1, I suppose.
There are some typos in the proposal you could fix, though :)
@rrelyea Here's the command and the list for Rawhide:
➤ dnf repoquery --releasever=rawhide --disablerepo=\* --enablerepo=fedora-\*source --whatrequires nss-devel Last metadata expiration check: 0:00:10 ago on Mon 15 Jun 2020 11:28:57 AM EDT. 389-ds-base-0:1.4.4.3-1.fc33.src NetworkManager-l2tp-0:1.8.2-1.fc33.src arc-gui-clients-0:0.4.6-22.fc33.src centerim-1:4.22.10-31.fc32.src ceph-2:15.2.3-1.fc33.src certmonger-0:0.79.9-1.fc32.src chromium-0:81.0.4044.138-1.fc33.src corosync-qdevice-0:3.0.0-8.fc33.src dogtag-pki-0:10.8.3-1.fc33.src ecryptfs-utils-0:111-20.fc32.src esc-0:1.1.2-5.fc32.src fence-virt-0:1.0.0-2.fc33.src firefox-0:77.0.1-2.fc33.src freeipa-0:4.8.6-2.fc33.src gdm-1:3.37.1-2.fc33.src ggz-base-libs-0:0.99.5-27.fc32.src java-1.8.0-openjdk-1:1.8.0.252.b02-0.0.ea.fc33.src java-1.8.0-openjdk-aarch32-1:1.8.0.252.b09-1.fc33.src java-11-openjdk-1:11.0.8.5-0.0.ea.fc33.src java-latest-openjdk-1:14.0.1.7-3.rolling.fc33.src jss-0:4.6.4-1.fc33.src kronosnet-0:1.16-1.fc33.src libblockdev-0:2.24-2.fc33.src libcacard-3:2.7.0-4.fc32.src liboauth-0:1.0.3-14.fc32.src libreswan-0:3.32-2.fc33.src libsrtp-0:2.3.0-2.fc32.src mate-settings-daemon-0:1.24.0-1.fc32.src mod_nss-0:1.0.17-10.fc32.src mod_revocator-0:1.0.3-34.fc32.src mozldap-0:6.0.5-26.fc32.src nordugrid-arc-0:6.6.0-2.fc33.src nut-0:2.7.4-32.fc33.src pcp-0:5.1.0-1.fc33.src perl-Mozilla-LDAP-0:1.5.3-33.fc33.src pesign-0:0.112-30.fc33.src pidgin-0:2.13.0-20.fc33.src pki-core-0:10.8.3-3.fc33.src python-nss-0:1.0.1-19.fc33.src seamonkey-0:2.53.2-2.fc33.src slapi-nis-0:0.56.5-2.fc33.src sssd-0:2.3.0-2.fc33.src suricata-0:5.0.3-2.fc33.src systemtap-0:4.3-0.20200530git6d50a5cadb64.fc33.src thunderbird-0:68.8.0-2.fc33.src volume_key-0:0.3.12-8.fc33.src
Two requests:
1) Can we get a list of affected packages? Specifically, I am concerned about any high profile packages affected.
2) The benefit to Fedora is listed, but are there any risks to not upgrading to this version of NSS?
* AGREED: FESCo asks rrelyea to rephrase the request and add details about the expected impact, particularly on rebuilds and revisit in a week (+8, 0, -0) (contyk, 15:34:38)
Metadata Update from @ignatenkobrain: - Issue assigned to rrelyea
@rrelyea bump?
@rrelyea Any updates here?
@rrelyea ping
@rrelyea ping. We're waiting on input from you on this one.
Here are the packages that use CK_GCM_PARAM and likely need an update:
libreswan: There is already an upstream patch. It may already be in fedora. libstrp: most likely will need to be fixed. seamonkey: Appears to already have the upstream patch. thunderbird: The source package appears to have it's own imbedded version of NSS. It may need to pick up the upstream firefox patch.
I have not been able to scan the following packages yet (because the broke automated scripts): rpmbuld -bp failed: chromium: firefox: I know firefox already has upstream patches for the issue and those patches are almost certainly in fedora already. nut:
java*, corosync-dqdevice, mate-settings-deamon
All the other packages on the list are fine. I'll come back with the status for chromium, nut, and java as I finish those scans.
Two requests: 1) Can we get a list of affected packages? Specifically, I am concerned about any high profile packages affected.
I think chromium and java are the last two I need to verify of high profile packages.
2) The benefit to Fedora is listed, but are there any risks to not upgrading to this version of NSS? By version, do you mean nss 3.53.1 or do you mean reverting the patch we put into 3.53.1 so old programs don't break immediately? If you mean the former, it's required for the latest version of firefox, and will continue to be required in the future. If you mean the latter, the risk is divergence from upstream and carrying along the path we put in perpetuity. It also means we won't be compatible with new hardware tokens coming out.
Ok, here are the packages that need a closer look by the maintainers: Mozilla projects firefox, thunderbird, and seamonkey: Upstream already has patches. I think those patches are already in fedora. libreswan: Upstream already has patches java-11-openjdk: It seems java is fine. It uses CK_GCM_PARAMS, but makes it's own definition (which looks like it's the new nss definition). It should be verified by the maintainer. libsrtp: could potentially have a problem and should be verified.
Everything else came back clean. Not sure what to do this this ticket from here...
bob
I think you've provided the information we needed, so this proposal will now have my +1 vote.
Since FESCo explicitly asked for further information, I am going to treat the start date of the voting period as the time when the last of the information was provided: 2020-07-29. Therefore, the normal voting period will continue through 5 August.
+1
I'm requesting that we fast-track this, it has been delayed long enough already.
Metadata Update from @zbyszek: - Issue tagged with: fast track
After a week, I count the vote as (+4,0,-0). Processing this proposal as accepted.
Metadata Update from @churchyard: - Issue tagged with: pending announcement
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/KRAIQZHW2ROCVFXGOSKQMVBUZWYL2FYG/
Metadata Update from @churchyard: - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
Metadata Update from @bcotton: - Issue untagged with: F34 - Issue set to the milestone: Fedora 34
Log in to comment on this ticket.