1640963 - Set NSS_PKCS_2_0_COMPAT for ESR68

Status: RESOLVED WONTFIX

(Core :: Security: PSM, enhancement, P1)

Description

[J.C. Jones [:jcj] (he/they)]

[Tracking Requested - why for this release]:

We added NSS_PKCS_2_0_COMPAT to NSS 3.52 to enable fallbacks for struct changes. ESR68 won't use the new PKCS3 structs, so it should really set this compiler flag to avoid runtime incompatibility if used with a newer-than-specified NSS release (newer than NSS 3.44 which ships with ESR).

Comment 1

[J.C. Jones [:jcj] (he/they)]

Just adding DEFINES['NSS_PKCS_2_0_COMPAT'] = True to security/moz.build isn't sufficient, it looks like we might need to add a flag to the gyp configuration that can be toggled.

Comment 2

[J.C. Jones [:jcj] (he/they)]

Attachment: Bug 1640963 - Add a build config option to set NSS_PKCS_2_0_COMPAT r?kjacobs

Comment 3

[J.C. Jones [:jcj] (he/they)]

Attachment: Bug 1640963 - ESR68 - Enable PKCS 2.0 compatibility mode for NSS 3.52+ r?kjacobs

Comment 4

[Ryan VanderMeulen (PTO, back July 27)]

When does NSS 3.52 ship? We're already in the middle of RC week for the 68.9esr release.

Comment 5

[J.C. Jones [:jcj] (he/they)]

It shipped 1 May 2020. https://wiki.developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.52_release_notes

I'm not sure how common it is for distros to use newer NSS than the one we define for ESR, but it brought up Bug 1637488..

Worst case scenario if we don't do this, we have to write some documentation recommending people use NSS 3.44.4 for ESR 68.x and not a later NSS.

I'll check in with Kevin on the reviews though.

Comment 6

[J.C. Jones [:jcj] (he/they)]

Mmm, these patches wouldn't actually solve the issue anyway, because if they're using a system NSS, then it's already built. In my defense, it was late last night when I fashioned these.

Kevin, do we have any options left that are compatible for NSS 3.44 and 3.53? A #define in PSM or something?

Comment 7

[Ryan VanderMeulen (PTO, back July 27)]

Given where we are in the current cycle (and absent any complaining about it over the past few weeks), I think we should stick with "Don't do that" guidance for now. I'm open to taking a patch for the 68.10 release shipping in late June if we think it's needed, though.

Comment 8

[Kevin Jacobs [:kjacobs]]

(In reply to J.C. Jones [:jcj] (he/him) [increased latency due to COVID-19] from comment #6)

Mmm, these patches wouldn't actually solve the issue anyway, because if they're using a system NSS, then it's already built. In my defense, it was late last night when I fashioned these.

Kevin, do we have any options left that are compatible for NSS 3.44 and 3.53? A #define in PSM or something?

I think #define NSS_PKCS11_2_0_COMPAT 1 somewhere near each non-NSS include of struct CK_GCM_PARAMSwould work, but I'm curious if we can't just use the same approach as https://searchfox.org/mozilla-central/source/third_party/prio/moz.build#49? As long as the define is present when we pull in the headers, we should be good.

Comment 9

[J.C. Jones [:jcj] (he/they)]

Given the short life of ESR 68 past this point, let's call this WONTFIX for now and if things warrant it, we can reopen for 68.10