Feature #5774
Robust time syncing
100%
Description
See the blueprint.
Subtasks
Related issues
History
#1 Updated by intrigeri about 6 years ago
- Starter set to No
#2 Updated by BitingBird over 5 years ago
- Subject changed from robust time syncing to Robust time syncing
#3 Updated by BitingBird almost 5 years ago
- Related to Feature #6112: Safer tordate parameters added
#4 Updated by BitingBird almost 5 years ago
- Related to Feature #5773: Revisit network fingerprinting design wrt. NTP added
#5 Updated by BitingBird almost 5 years ago
- Related to Feature #5424: Think about tordate htpdate changes added
#6 Updated by intrigeri almost 5 years ago
- Category set to Time synchronization
#7 Updated by intrigeri almost 5 years ago
- Related to Feature #8977: Get rid of tordate added
#8 Updated by Dr_Whax almost 5 years ago
After discussing this with various knowledgeable Tor folks, the consensus seem to be that we just have to ask the user to set the time so we can bootstrap the Tor process.
#9 Updated by intrigeri almost 5 years ago
After discussing this with various knowledgeable Tor folks, the consensus seem to be that we just have to ask the user to set the time so we can bootstrap the Tor process.
May we please have the reasoning behind this conclusion?
#10 Updated by intrigeri almost 5 years ago
- Assignee set to Dr_Whax
- QA Check set to Info Needed
#11 Updated by intrigeri over 4 years ago
intrigeri wrote:
After discussing this with various knowledgeable Tor folks, the consensus seem to be that we just have to ask the user to set the time so we can bootstrap the Tor process.
May we please have the reasoning behind this conclusion?
I would still love to hear more about this => ping?
In the meantime, I did some research on my side, and it seems that ChromeOS does something very similar to DrWhax' proposal:
- https://code.google.com/p/chromium/issues/detail?id=232066#c105
- https://codereview.chromium.org/247663003/
Sadly, most of their design docs, UI mockups etc. are apparently not accessible to non-Google employees or something, so it's not easy to understand why they did what. Still, the resulting code is there: https://src.chromium.org/viewvc/chrome?revision=266431&view=revision
#12 Updated by intrigeri over 4 years ago
- Blueprint set to https://tails.boum.org/blueprint/robust_time_syncing/
#13 Updated by intrigeri over 4 years ago
- Related to deleted (Feature #8977: Get rid of tordate)
#14 Updated by intrigeri over 4 years ago
- Duplicated by Feature #8977: Get rid of tordate added
#15 Updated by intrigeri over 4 years ago
- Description updated (diff)
Moved all the relevant info from this ticket to the blueprint.
#16 Updated by intrigeri over 4 years ago
- Status changed from Confirmed to In Progress
- Assignee deleted (
Dr_Whax) - QA Check deleted (
Info Needed)
#17 Updated by intrigeri over 4 years ago
- Target version set to Hardening_M1
Importing target version that anonym had set on #8977, and with which I fully agree.
#18 Updated by intrigeri over 4 years ago
- Blocked by Feature #5462: Persistence preset: Tor state added
#19 Updated by intrigeri over 4 years ago
- Blocked by deleted (Feature #5462: Persistence preset: Tor state)
#20 Updated by intrigeri over 4 years ago
- Blocks Feature #5462: Persistence preset: Tor state added
#21 Updated by intrigeri over 4 years ago
- Type of work changed from Research to Code
The user story and tentative roadmap have been ACK'd on -ux@ => next step is to actually implement this.
#22 Updated by intrigeri over 4 years ago
- Blocked by Feature #6284: Display time in local timezone added
#23 Updated by sajolida over 4 years ago
- Related to Bug #9256: Don't restart Tor after setting the right clock added
#24 Updated by sajolida about 4 years ago
- Target version changed from Hardening_M1 to 2017
#25 Updated by intrigeri about 4 years ago
- Target version changed from 2017 to 2018
#26 Updated by sajolida almost 4 years ago
- Related to Feature #10819: Allow changing timezone in session added
#27 Updated by intrigeri over 3 years ago
- Related to Bug #11285: Check if we need to disable UseDefaultFallbackDirs in Tor 0.2.8+ added
#28 Updated by bertagaz over 3 years ago
- Related to Bug #11589: Time syncing over bridge is fragile added
#29 Updated by Dr_Whax over 3 years ago
- Description updated (diff)
- Assignee set to bertagaz
- Target version deleted (
2018)
#30 Updated by intrigeri over 3 years ago
I'm a bit lost: did we keep this on our roadmap in the end? bertagaz, did you volunteer? If yes, please set the correct target version. Thanks!
#31 Updated by Dr_Whax over 3 years ago
intrigeri wrote:
I'm a bit lost: did we keep this on our roadmap in the end? bertagaz, did you volunteer? If yes, please set the correct target version. Thanks!
It was on the roadmap but without a deadline.
#32 Updated by intrigeri almost 3 years ago
- Related to Feature #12094: Persistence preset: localized timezone for displayed time added
#33 Updated by BitingBird over 2 years ago
- Description updated (diff)
- Target version set to 2019
#34 Updated by BitingBird over 2 years ago
- Description updated (diff)
#35 Updated by intrigeri about 2 years ago
The thread that starts at https://mailman.boum.org/pipermail/tails-dev/2017-December/011945.html shows that this is more urgent than we thought. Is it an option to swap this with something else that was on your (plural) roadmap for 2018?
#36 Updated by u almost 2 years ago
- Related to Feature #5366: When htp fails the user should be prompted added
#37 Updated by intrigeri about 1 year ago
- Description updated (diff)
- Assignee deleted (
bertagaz) - Target version deleted (
2019)
As per roadmap updating process. Of course, feel free to re-add it once there's a team :)
#38 Updated by intrigeri 4 months ago
- Blocks Bug #15168: Improve UX when hardware clock is set to localtime in a timezone too far from UTC added
#39 Updated by intrigeri 4 months ago
- Blocks Bug #15548: Tails can't establish a connection with obfs4 bridges and a hardware clock too far away from UTC added
#40 Updated by intrigeri 4 months ago
- Blocks deleted (Bug #15168: Improve UX when hardware clock is set to localtime in a timezone too far from UTC)