On 15 September 2017 at 10:35, Alex Davis <ada...@mozilla.com> wrote:
> If we were more aggressive and did 52, we'd cover 87.7% of users... which >> seems *too* aggressive but perhaps we can see if we can try to nudge >> people to upgrade first. > > > I'd like to make a correction. It's 92.62% of users that are 52 or higher. > That does seem aggressive, but we could also consider a nuanced approach to phasing out support, because we have the following possibilities for what "removing support" means: * We stop proactively testing on versions < X, but accept and fix reported bugs on that version * We wont fix bugs that only affect versions < Y, but don't prevent users from attempting to use them * We proactively error out when we detect a login attempt with version < Z We also have to consider whether we do the same behaviour for sync logics (where we can be reasonably considered a part of the browser and depend on browser-specific behaviour) and OAuth logins on the web (where we're just another webpage, and need to worry about non-Firefox browsers as well) Ryan On Thu, Sep 14, 2017 at 4:57 PM, Mark Hammond <mhamm...@mozilla.com> wrote: > On 14/9/17 2:43 PM, Ryan Kelly wrote: > > On 15 September 2017 at 05:46, Mark Hammond <mhamm...@mozilla.com > > <mailto:mhamm...@mozilla.com>> wrote: > > > > Another way to look at this is: at some point, Mozilla makes a > decision > > that even the most serious security vulnerability which can cause > > significant harm to users will not be fixed in some older versions. I > > find it difficult to justify that the FxA team should be held to a > > higher standard - and in some cases, it's even possible that having > FxA > > work on such older, vulnerable Firefoxes could potentially cause > *more* > > harm to the user. > > > > > > I strongly support this as a lower-bound on our ambitions here. Mark, > > is there a concrete policy based around ESR etc for these decisions? > > I asked on #security - a summary of the conversation is below, but the > tl;dr is that we've never shipped a security patch before the *current* > ESR, even known zero-days. However, there's no specific policy that say > we never will. > > Mark > > > <markh> is there a documented policy somewhere that describes where we > will and will not fix security bugs? ie, I'm basically looking for a > policy that says "even serious security bugs will not be back-ported to > current-esr-minus-1" or similar > > > <•dveditz> markh: about the most definitive thing we've promised is at > https://www.mozilla.org/en-US/firefox/organizations/faq/ > > > <•dveditz> "Maintenance of each ESR, through point releases, is > limited to high-risk/high-impact security vulnerabilities and in rare > cases may also include off-schedule releases that address live security > vulnerabilities. Backports of any functional enhancements and/or > stability fixes are not in scope. " > ... > > > <markh> dveditz: so has there been a security bug so bad we've ever > ported it back to a version *before* the current ESR and cut a new > release of that old version? > > > dveditz> not that I remember > ... > > <•dveditz> If we still have a bunch of people on that branch and it's > EOL and there's a live attack in the wild maybe we'd ship an update? > > <•dveditz> worms are bad > > <•dveditz> we've hardly ever fixed actual 0-days though. Mostly we're > backporting vulnerability fixes, and we wouldn't do that kind of > prophylactic back-port to an unsupported branch. > > > dveditz> won't say "never", but extremely unlikely and probably would > need approving at the top of the company >
_______________________________________________ Sync-dev mailing list Sync-dev@mozilla.org https://mail.mozilla.org/listinfo/sync-dev
