Closed Bug 1583326 Opened 6 years ago Closed 6 years ago

ESR computation in nsRFPService.cpp will need to be updated when we switch to 4 week releases

Categories

(Core :: Privacy: Anti-Tracking, task)

Product:
Core
Component:
Privacy: Anti-Tracking
Type:
task
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1599188

People

(Reporter: mkaply, Assigned: cpeterson)

References

Details

There is code in nsRFPService.cpp that tries to compute the next ESR.

https://searchfox.org/mozilla-central/rev/153feabebc2d13bb4c29ef8adf104ec1ebd246ae/toolkit/components/resistfingerprinting/nsRFPService.cpp#683

This code will be incorrect when we switch to 4 week release cycles.

Need to track this going forward.

Component: DOM: Security → Privacy: Anti-Tracking
Flags: needinfo?(tom)

Ryan, do you know how the ESR versioning is going to change?

Flags: needinfo?(ryanvm)

AFAIK, all we've committed to at this point is that we'll continue to release ESRs on a yearly cadence. I don't believe we've specifically determined which version will be the next release, however. Assuming a 4 week cycle, every ~13 releases, I guess? Redirecting to Ritu in case she has any further insight on this question.

Flags: needinfo?(ryanvm) → needinfo?(rkothari)

In addition to what Ryan said, the yearly release is planned for ~June of the year. And based on the current 2020-2021 schedule projections, major ESR versions after ESR68 will be ESR78 June 2020, ESR91 June 2021. Note: These dates/versions are subject to change.

However, the major/minor ESR versioning scheme and process remains the same, even with 4-week release cycles.

Flags: needinfo?(rkothari)

(In reply to Mike Kaply [:mkaply] from comment #0)

There is code in nsRFPService.cpp that tries to compute the next ESR.

This must be new code because our ESR cadence has been ~7 or 8 cycles (v68, v60, v52, v45, v38) so it could never have been accurate at predicting next ESR version anyways. This should be irrespective of the 4-week cycle. Right?

(In reply to Ritu Kothari (:ritu) from comment #4)

(In reply to Mike Kaply [:mkaply] from comment #0)

There is code in nsRFPService.cpp that tries to compute the next ESR.

This must be new code because our ESR cadence has been ~7 or 8 cycles (v68, v60, v52, v45, v38) so it could never have been accurate at predicting next ESR version anyways. This should be irrespective of the 4-week cycle. Right?

Yeah, I think we've updated it for every ESR we've actually shipped; heh.

(In reply to Tom Ritter [:tjr] (needinfo for responses to sec-[approval/ratings/advisories/cve's]) from comment #5)

(In reply to Ritu Kothari (:ritu) from comment #4)

(In reply to Mike Kaply [:mkaply] from comment #0)

There is code in nsRFPService.cpp that tries to compute the next ESR.

This must be new code because our ESR cadence has been ~7 or 8 cycles (v68, v60, v52, v45, v38) so it could never have been accurate at predicting next ESR version anyways. This should be irrespective of the 4-week cycle. Right?

Yeah, I think we've updated it for every ESR we've actually shipped; heh.

Wow, that sounds fragile! Is there a robust mechanism to ensure we'll remember to do so?

Note that the algorithm should be checked several releases ahead of schedule

  • e.g for ESR78 the change/check should technically land in 77 (see bug 1511763 and comments where it had to be clarified that the change should land in 67 ahead of 68 from a purist point of view)

However, in this case, because the cadence changed upwards, the current code will report a new value when it hits 76, so technically you should land/check any change in nightly 75

  • It can of course be after the fact (e.g. early in the affected nightly release rather than before and/or backported to dev etc if the "deadline" is missed). Nightly and Dev are considered "edge cases" (see bug 1466027), so it's not a deal breaker, as long as the correct value reported is always what we want in Stable

I don't know what internal mechanisms you have at your disposal, but the at the very least, the alert/check message should apply to the release prior to the new ESR value according to the current code (e.g a sticky bugzilla issues tagged as fingerprinting affects 75?). But this does not allow for the case where the cadence is reduced, so there's that as well.

Nightly 75 is slated for 2020-Feb-10

(In reply to :ehsan akhgari from comment #6)

Wow, that sounds fragile! Is there a robust mechanism to ensure we'll remember to do so?

Well, this is the mechanism. It's far from ideal; but basically as soon as someone tries to run a resistfingerprinting Debug test on an ESR build that doesn't match the formula - we assert. This should happen during testing prior to cutting an ESR release. Which is way later in the cycle than it should happen.

I'm very open to changing it, the entire point of this code is "Find the major version of the latest ESR release" - I don't think we have a way to do that besides this fragile version fiddling.

Flags: needinfo?(tom)
See Also: → 1599188

I have a patch to fix this bug (and bug 1599188). I will post it for review (in bug 1599188) when the 78 Nightly cycle starts.

Assignee: nobody → cpeterson
Status: NEW → ASSIGNED

(In reply to Chris Peterson [:cpeterson] from comment #10)

I have a patch to fix this bug (and bug 1599188). I will post it for review (in bug 1599188) when the 78 Nightly cycle starts.

Chris, I sent you (and tjr) an email. Some RFP navigator protection is already broken in 76. This also applies to the http header

Same argument as https://bugzilla.mozilla.org/show_bug.cgi?id=1511763#c8 .. the patches need to land in 76, not 78: i.e before the old algorithm kicks in and uses 76

See also bug 1529391 as a completely different solution which would avoid all the trouble which is discussed here.

Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.