I don't know if the following is necessary, but here are my thoughts and questions: (In reply to Benjamin Beurdouche [:beurdouche] from comment #55) > As I just released NSS 3.72 (2021-10-28), and looking at the calendar [0], there are two releases that could work well for landing this fix: > NSS 3.73 on 2021-12-02 - or - NSS 3.74 on 2022-01-06. > > I currently lean towards aiming at NSS 3.73 which leaves us with 4 weeks to take additional disclosure actions. > In that scenario, we could notify the distros list on November 22nd (10 days prior the release). When do you intend to create the public commit? IIUC, you suggest: 2021-12-02 When do you intend to provide the NSS patch for the distro people? Do you need to do that on the day you announce it to the distro list? Or is it sufficient to do that by the end of the 14 day period? As soon as you provide the patch to the distro people, you might see public package builds that contain the patch, so this is equivalent to publishing the fix, and therefore I think that you could publicly commit to NSS on the same day as giving to distro people. Is it necessary to immediately release beta and esr91 immediately after you make the public commit? If yes, the suggested date 2021-12-02 may not be ideal, because it's too close to the scheduled release on 2021-12-07, and it might be a challenge for release engineering to handle two releases within a week. Regardless of the timing for mozilla-central and a new NSS version, you might require at least two .x releases for stable NSS releases, for the one used by Firefox Beta, and for the one used by Firefox ESR 91.x. If you do it in the middle of the regular 4 week update cycle, then you don't need to immediately create the next NSS release, it's sufficient to have it in NSS trunk and in FF nightly. If the patch can be ready soon, then you could use the following schedule, assuming Firefox releng would agree with it, and also assuming that you can ask distros to delay building public packages until 2 days before the end of the 14 days period: - 2021-11-09: announce to distros list - 2021-11-21: public commit to NSS, give patch to distro list, create release tags NSS 3.71.x, NSS 3.72.x - 2021-11-23: release FF 94.0.x, FF Beta 95.x, FF ESR 91.3.x, and announce the NSS 3.71.x and NSS 3.72.x releases Linux distributions will need to patch their older system NSS releases. For example Debian 10 uses NSS 3.42, and Ubuntu 20.04 uses NSS 3.49, Debian 11 uses NSS 3.61. Updating NSS is the only known defense for Gnome Evolution, to protect it from being exploitable by received email. Will the patch to NSS easily apply to all past versions? The answer to this influences how much time the distros need to prepare a merged NSS. For the current WIP, it seems easy, the patch seems to directly apply to NSS 3.42.
Bug 1737470 Comment 58 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I don't know if the following is necessary, but here are my thoughts and questions: (In reply to Benjamin Beurdouche [:beurdouche] from comment #55) > As I just released NSS 3.72 (2021-10-28), and looking at the calendar [0], there are two releases that could work well for landing this fix: > NSS 3.73 on 2021-12-02 - or - NSS 3.74 on 2022-01-06. > > I currently lean towards aiming at NSS 3.73 which leaves us with 4 weeks to take additional disclosure actions. > In that scenario, we could notify the distros list on November 22nd (10 days prior the release). When do you intend to create the public commit? IIUC, you suggest: 2021-12-02 When do you intend to provide the NSS patch for the distro people? Do you need to do that on the day you announce it to the distro list? Or is it sufficient to do that by the end of the 14 day period? As soon as you provide the patch to the distro people, you might see public package builds that contain the patch, so this is equivalent to publishing the fix, and therefore I think that you could publicly commit to NSS on the same day as giving to distro people. Is it necessary to immediately release beta and esr91 immediately after you make the public commit? If yes, the suggested date 2021-12-02 may not be ideal, because it's too close to the scheduled release on 2021-12-07, and it might be a challenge for release engineering to handle two releases within a week. Regardless of the timing for mozilla-central and a new NSS version, you might require at least two .x releases for stable NSS releases, for the one used by Firefox Beta, and for the one used by Firefox ESR 91.x. [Edit]: ~~If you do it in the middle of the regular 4 week update cycle, then you don't need to immediately create the next NSS release, it's sufficient to have it in NSS trunk and in FF nightly.~~ With the following schedule you'd also require an additional NSS release for the latest FF release. If the patch can be ready soon, then you could use the following schedule, assuming Firefox releng would agree with it, and also assuming that you can ask distros to delay building public packages until 2 days before the end of the 14 days period: - 2021-11-09: announce to distros list - 2021-11-21: public commit to NSS, give patch to distro list, create release tags NSS 3.68.x, NSS 3.71.x, NSS 3.72.x - 2021-11-23: release FF 94.0.x, FF Beta 95.x, FF ESR 91.3.x, and announce the NSS 3.68.x, NSS 3.71.x and NSS 3.72.x releases Linux distributions will need to patch their older system NSS releases. For example Debian 10 uses NSS 3.42, and Ubuntu 20.04 uses NSS 3.49, Debian 11 uses NSS 3.61. Updating NSS is the only known defense for Gnome Evolution, to protect it from being exploitable by received email. Will the patch to NSS easily apply to all past versions? The answer to this influences how much time the distros need to prepare a merged NSS. For the current WIP, it seems easy, the patch seems to directly apply to NSS 3.42. [Edit]: Added need for 3.68.x