WRT to the deadlines: If the decision is to sync up, I think it's worth noting that Firefox probably needs to release 2-3 weeks after a Chrome "release date" to achieve this in practice.
Why? Firefox updates take ~10days from release date to reach previous version numbers. Chrome _can_ do it in the same time, but sometimes they slow update propagation considerably - and the distrust events could very well be reasons to do this. Take for example Chrome 57: Release date for desktop was March 9 [1], but propagation was throttled heavily for the first ~20 days, resulting in a total of ~30 days. [2] Chrome 57 for Android, supposedly released March 16 - always a week later than desktop! - was also held back for most? users for ~3-4 weeks iirc (can't find a graph right now, sorry). So unless Mozilla is eager to deal with most of the immediate outfall of the trust changes on its own (at which point we might as well set stricter deadlines), it should strategically fall behind. Dates in question: * Firefox 60 on 2018-05-01 for old PKI notBefore >=2016-06 -> already close, only 2 weeks after * Firefox 64 on 2018-11-27 for the full distrust -> 5 weeks after. Bonus: All the 1-year certs from the old PKI will have expired as well. [1] https://chromereleases.googleblog.com/2017/03/stable-channel-update-for-desktop.html [2] http://gs.statcounter.com/browser-version-market-share/desktop/worldwide/#daily-20170301-20170501 On Monday, July 31, 2017 at 2:01:57 PM UTC, Gervase Markham wrote: > On 29/07/17 23:45, Peter Bowen wrote: > > First, when the server authentication trust will bits be removed from > > the existing roots. This is of notable importance for non-Firefox > > users of NSS. Based on the Chrome email, it looks like they will > > remove trust bits in their git repo around August 23, 2018. When will > > NSS remove the trust bits? > > The NSS trust store represents Mozilla's decisions about what is > trustworthy. However, particularly if we match Chrome's dates, there is > a slightly unusual situation as we have taken a decision on > trustworthiness but, for other reasons, Firefox still trusts those certs > for a period. So one might well ask, should the decision be implemented > in NSS earlier than, or at the same time as, or even later than, Firefox > implements it? A good question. If you enjoy making things harder for other people you can go with earlier :-P . Seriously though, that would only make sense from a Mozilla release process perspective but is totally unexpected and annoying for any other NSS consumer - they will just have to postpone that NSS update or restore the roots temporarily. I think it makes most sense to land Firefox internal distrust shortly before branching, like Chrome, use beta for gauging impact, release, then ~2 weeks after release date do a NSS point release with only the certdata changes for other consumers and future Firefox versions. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
