<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If we were more aggressive and did 52, we'd cover 87.7% of users... which seems <b>too</b> aggressive but perhaps we can see if we can try to nudge people to upgrade first.</blockquote><div><br></div><div>I'd like to make a correction. It's 92.62% of users that are 52 or higher.</div><div><br></div><div>Thanks Thom for catching that misinterpretation!<br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div></div><div>--<br>Alex Davis <span>// Mountain View</span></div><div>Product Manager // FxA & Sync<br></div>(415) 769-9247</div><span></span></div><div>IRC & Slack: adavis<br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Thu, Sep 14, 2017 at 4:57 PM, Mark Hammond <span dir="ltr"><<a href="mailto:mhammond@mozilla.com" target="_blank">mhammond@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 14/9/17 2:43 PM, Ryan Kelly wrote:<br>
> On 15 September 2017 at 05:46, Mark Hammond <<a href="mailto:mhammond@mozilla.com">mhammond@mozilla.com</a><br>
</span><span class="">> <mailto:<a href="mailto:mhammond@mozilla.com">mhammond@mozilla.com</a>>> wrote:<br>
><br>
> Another way to look at this is: at some point, Mozilla makes a decision<br>
> that even the most serious security vulnerability which can cause<br>
> significant harm to users will not be fixed in some older versions. I<br>
> find it difficult to justify that the FxA team should be held to a<br>
> higher standard - and in some cases, it's even possible that having FxA<br>
> work on such older, vulnerable Firefoxes could potentially cause *more*<br>
> harm to the user.<br>
><br>
><br>
> I strongly support this as a lower-bound on our ambitions here. Mark,<br>
> is there a concrete policy based around ESR etc for these decisions?<br>
<br>
</span>I asked on #security - a summary of the conversation is below, but the<br>
tl;dr is that we've never shipped a security patch before the *current*<br>
ESR, even known zero-days. However, there's no specific policy that say<br>
we never will.<br>
<br>
Mark<br>
<br>
> <markh> is there a documented policy somewhere that describes where we<br>
will and will not fix security bugs? ie, I'm basically looking for a<br>
policy that says "even serious security bugs will not be back-ported to<br>
current-esr-minus-1" or similar<br>
<br>
> <•dveditz> markh: about the most definitive thing we've promised is at<br>
<a href="https://www.mozilla.org/en-US/firefox/organizations/faq/" rel="noreferrer" target="_blank">https://www.mozilla.org/en-US/<wbr>firefox/organizations/faq/</a><br>
<br>
> <•dveditz> "Maintenance of each ESR, through point releases, is<br>
limited to high-risk/high-impact security vulnerabilities and in rare<br>
cases may also include off-schedule releases that address live security<br>
vulnerabilities. Backports of any functional enhancements and/or<br>
stability fixes are not in scope. "<br>
...<br>
<br>
> <markh> dveditz: so has there been a security bug so bad we've ever<br>
ported it back to a version *before* the current ESR and cut a new<br>
release of that old version?<br>
<br>
> dveditz> not that I remember<br>
...<br>
> <•dveditz> If we still have a bunch of people on that branch and it's<br>
EOL and there's a live attack in the wild maybe we'd ship an update?<br>
> <•dveditz> worms are bad<br>
> <•dveditz> we've hardly ever fixed actual 0-days though. Mostly we're<br>
backporting vulnerability fixes, and we wouldn't do that kind of<br>
prophylactic back-port to an unsupported branch.<br>
<br>
> dveditz> won't say "never", but extremely unlikely and probably would<br>
need approving at the top of the company<br>
</blockquote></div><br></div>