Closed Bug 1211586 Opened 5 years ago Closed 4 years ago
upgrade mozilla 42 beta to nspr 4
.10 .10 and nss 3 .19 .4 on october 16 (release candidate first, final on october 19)
These NSPR and NSS upgrades are driven by the bugs listed in the dependency list, which are under embargo. We intend to land these patches into public NSS repository on October 15, and immediately afterwards into mozilla-inbound/central, for initial testing using the Firefox test automation. We should be ready to land release candidates of NSPR/NSS into the Firefox branch on October 16, and if it works fine, declare the final NSPR/NSS releases and land them into the Firefox branch by October 19. We're trying to land these patches as late as possible, but because you'll need time for Firefox release preparation, and testing of final Firefox builds, we're planning to do so two weeks prior to the scheduled November 3rd release date. Please let me know if this plan doesn't work for you.
[Approval Request Comment] fix critical security issues in NSPR and NSS Could you please approve by to October 15? Thank you.
Attachment #8669836 - Flags: approval-mozilla-beta?
Attachment #8669836 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Just a version number nit: I realized we don't need to use a version number with 4 pieces, we can use 3.19.4 for the version number that Firefox 42 will get.
Summary: upgrade mozilla 42 beta to nspr 4.10.10 and nss 22.214.171.124 on october 16 (release candidate first, final on october 19) → upgrade mozilla 42 beta to nspr 4.10.10 and nss 3.19.4 on october 16 (release candidate first, final on october 19)
https://hg.mozilla.org/releases/mozilla-beta/rev/170d29280d87 Note these are release candidates. The final tags (plus the change to bump configure.in) are expected to land on Monday, hopefully without any code changes.
Kai, do you have an eta for today landing? I would like to take in beta 8 (go to build today).
Whiteboard: [post-critsmash-triage] → [post-critsmash-triage][adv-main42-]
... and this is where the absurdity of the version check in configure.in hits: 3.20 fulfills the build requirement, yet, is a version that shouldn't be used for the same reason versions under 3.19.4 shouldn't.
(In reply to Mike Hommey [:glandium] from comment #7) > ... and this is where the absurdity of the version check in configure.in > hits: 3.20 fulfills the build requirement, yet, is a version that shouldn't > be used for the same reason versions under 3.19.4 shouldn't. That's true, do you have a better idea? At least, the current approach ensures that those users, who had originally used the old 3.19.3, and had not yet upgraded NSS, will notice the need to upgrade. Those users (or distributions) that are already using a newer NSS than the one originally required by Firefox, might have a habit to update NSS more frequently anyway, and thus might notice the availability of NSS 3.20.1. I understand it's an incomplete solution, but I don't have a better idea. It would be best to force everyone to always upgrade to the most recent stable NSS versions, but convincing everyone to accept the risks, or potential change in behaviour, isn't easy either.
You need to log in before you can comment on or make changes to this bug.