Closed Bug 1397061 Opened 2 years ago Closed 2 years ago
Firefox incorrectly says my system date is wrong
Opening https://expired.badssl.com/ shows: > Your computer is set to 9/5/17, when it should be 9/3/17. To fix this problem, change your date and time settings to match the correct time. However, my system date is correct: > $ date > Tue Sep 5 16:33:31 PDT 2017 Following a discussion on #moco, :MattN suggested opening this bug along with a screenshot of services.blocklist.* from about:config. Running Nightly 57.0a1 on macOS 10.12.6, build ID 20170905100117.
That's a big clock_skew_seconds, isn't it?
> That's a big clock_skew_seconds, isn't it? 50 hours, that could explain the 2 days differences... We experiences some issues with the CDN in the past but it is not supposed to cache for more than a few hours. The blocklist checks timestamp looks good: >>> Date(1504449) >>> "Wed Sep 06 2017 10:27:25 GMT+0200 (CEST)"
Err the timestamp is 3/9/2017 à 16:39:42 So it is possible that the clock_skew_seconds was calculated from this last checked timestamp.
:Ashish could you try to run the following command from a terminal: curl -s -i --compressed https://firefox.settings.services.mozilla.com/v1/buckets/monitor/collections/changes/records | grep '^Date: '
Here I have a clock_skew of 45 seconds
(In reply to Rémy Hubscher (:natim) from comment #5) > $ curl -s -i --compressed https://firefox.settings.services.mozilla.com/v1/buckets/monitor/collections/changes/records | grep '^Date: ' > Date: Wed, 06 Sep 2017 16:06:27 GMT About a day later, the timestamps are still the same... Does that mean my browser isn't updating the blocklist?
It is possible, I will needinfo Mat and Mark that might know more about it. In the meantime, you can use this add-on to force refresh the blocklist: https://github.com/leplatrem/aboutremotesettings
The clock skew is computed using the server date of https://firefox.settings.services.mozilla.com Since this service is running through a CDN, the Date header shifts along caching. If we setup CDN to have a TTL of 1 hour, the clock skew will be at most 1H on clients. Mark, is it acceptable? Wei, can you please tell us the currently configured TTL? Otherwise, we might have other services that we could rely on to obtain a reference date.
Flags: needinfo?(mathieu) → needinfo?(wezhou)
The CDN cache for https://firefox.settings.services.mozilla.com/ has the following TTL values: * Minimum TTL: 60 * Maximum TTL: 3600 * Default TTL: 300 The document about these values is in . tldr is that if the app doesn't provide HTTP headers such as Cache-Control max-age, Cache-Control s-maxage, or Expires, then cloudfront uses the default TTL, which is 300 seconds. If the app does provide those headers, then cloudfront takes into consideration the minimum TTL, the maximum TTL and the headers in order to determine how long it caches. Generally it won't cache more than maximum TTL (There is a table that documents how the actual TTL is calculated in ).  https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html#DownloadDistValuesMinTTL  https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html#ExpirationDownloadDist
OK thanks! So, what we should do, when computing the client clock skew is to take into account the ``Age`` header, which gives us the age in seconds. I'll submit a patch.
Comment on attachment 8982042 [details] Bug 1397061 - Adjust clock skew according to CDN cache age https://reviewboard.mozilla.org/r/248086/#review255756 Thanks!
Attachment #8982042 - Flags: review?(mgoodwin) → review+
Assignee: rhubscher → mathieu
Status: NEW → ASSIGNED
Target Milestone: --- → Firefox 62
Version: unspecified → Trunk
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/633f31aef218 Adjust clock skew according to CDN cache age r=mgoodwin
Backed out changeset 633f31aef218 (bug 1397061) for X clock skew failures on a CLOSED TREE Problematic push: https://hg.mozilla.org/integration/autoland/rev/633f31aef2189634eaeccec80ec707e095c744ce Failure: https://treeherder.mozilla.org/#/jobs?repo=autoland&filter-resultStatus=testfailed&filter-resultStatus=busted&filter-resultStatus=exception&filter-classifiedState=unclassified&fromchange=9c7dac7ac4d967155e4a74489decb5e4c7933475&selectedJob=182096423 Log: https://treeherder.mozilla.org/logviewer.html#?job_id=182096423&repo=autoland&lineNumber=1126 Backout: https://hg.mozilla.org/integration/autoland/rev/e42b6189ab12097554c2b247193797384371e58c [task 2018-06-06T15:05:49.772Z] 15:05:49 INFO - TEST-PASS | services/crypto/tests/unit/test_utils_sha1.js | took 7325ms [task 2018-06-06T15:05:51.647Z] 15:05:51 INFO - TEST-START | services/settings/test/unit/test_remote_settings.js [task 2018-06-06T15:07:01.111Z] 15:07:01 INFO - TEST-PASS | services/settings/test/unit/test_remote_settings.js | took 69463ms [task 2018-06-06T15:07:02.986Z] 15:07:02 INFO - TEST-START | services/settings/test/unit/test_remote_settings_poll.js [task 2018-06-06T15:07:23.841Z] 15:07:23 WARNING - TEST-UNEXPECTED-FAIL | services/settings/test/unit/test_remote_settings_poll.js | xpcshell return code: 0 [task 2018-06-06T15:07:23.842Z] 15:07:23 INFO - TEST-INFO took 20855ms
I modified the test to be less fagile and subject to timing. Tests now pass https://treeherder.mozilla.org/#/jobs?repo=try&revision=e8943f9655e1c6982980cbeefdecbe184b38c9ad
Pushed by email@example.com: https://hg.mozilla.org/integration/autoland/rev/030a10988648 Adjust clock skew according to CDN cache age r=mgoodwin
You need to log in before you can comment on or make changes to this bug.