#2400 F34 System-Wide Change: NSS CK_GCM_PARAMS change
Closed: Accepted 3 months ago by churchyard. Opened 5 months ago by bcotton.

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

5 months ago

@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

5 months ago

@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

4 months ago

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

3 months ago

Metadata Update from @churchyard:
- Issue close_status updated to: Accepted
- Issue status updated to: Closed (was: Open)

3 months ago

Login to comment on this ticket.

Metadata