#28591 closed defect (fixed)
Accept a future consensus for bootstrap
Reported by: | teor | Owned by: | teor |
---|---|---|---|
Priority: | Medium | Milestone: | Tor: 0.3.5.x-final |
Component: | Core Tor/Tor | Version: | |
Severity: | Normal | Keywords: | bootstrap, clock-skew, tor-guard, usability, ux, s8-errors, 035-roadmap-subtask, 035-triaged-in-20180711, 035-backport-unreached |
Cc: | iry, brade, mcs, intrigeri, torproject@… | Actual Points: | 0.5 |
Parent ID: | #28018 | Points: | |
Reviewer: | catalyst | Sponsor: |
Description
#24661 allows tor to bootstrap when the client's clock is ahead of the network by up to 1 day.
But clients can't bootstrap when the client's clock is behind the network by more than a few hours:
https://trac.torproject.org/projects/tor/ticket/24661#comment:18
Child Tickets
Change History (17)
comment:1 Changed 13 months ago by
Status: | assigned → needs_review |
---|
comment:2 Changed 12 months ago by
Reviewer: | → catalyst |
---|
comment:3 follow-up: 5 Changed 12 months ago by
Status: | needs_review → needs_revision |
---|
Thanks! Mostly looks good, but I haven't tested it yet. I left a minor comment on the pull request about a build failure that I get. When you fix that, I can try to do some manual tests. I can also try to fix it up myself later if you don't have the time.
comment:4 Changed 12 months ago by
Sponsor: | → Sponsor8-can |
---|
comment:5 Changed 12 months ago by
Status: | needs_revision → needs_review |
---|
Replying to catalyst:
Thanks! Mostly looks good, but I haven't tested it yet. I left a minor comment on the pull request about a build failure that I get. When you fix that, I can try to do some manual tests. I can also try to fix it up myself later if you don't have the time.
I fixed the build failure by making the code simpler.
comment:6 Changed 11 months ago by
Status: | needs_review → merge_ready |
---|
Thanks! Looks good. I did a little bit of manual testing with libfaketime.
comment:7 Changed 11 months ago by
Actual Points: | → 0.5 |
---|
comment:9 follow-up: 11 Changed 11 months ago by
Milestone: | Tor: 0.4.0.x-final → Tor: 0.3.4.x-final |
---|
I've squashed this as bug28591_035_squashed
and merged it to master. We can consider for an 0.3.5 backport, but I am a little unsure about the complexity.
comment:10 Changed 11 months ago by
Milestone: | Tor: 0.3.4.x-final → Tor: 0.3.5.x-final |
---|
comment:11 Changed 11 months ago by
Replying to nickm:
I've squashed this as
bug28591_035_squashed
and merged it to master. We can consider for an 0.3.5 backport, but I am a little unsure about the complexity.
I would not backport #28564 / commit a9c766c , consensus expiry code on relays has historically caused us a lot of issues.
If we backport #28591, let's do it in two stages:
comment:12 Changed 11 months ago by
Keywords: | s8-bootstrap removed |
---|---|
Sponsor: | Sponsor8-can |
comment:13 Changed 10 months ago by
Cc: | torproject@… added |
---|
comment:14 Changed 9 months ago by
Keywords: | 035-backport-unreached added |
---|---|
Resolution: | → fixed |
Status: | merge_ready → closed |
This code is too complex to backport: people who need better reliability under clock skew will have to upgrade to 0.4.0 or later.
comment:15 follow-up: 16 Changed 9 months ago by
Not sure if it's correct to leave it in the Tor: 0.3.5.x-final
milestone.
comment:16 Changed 9 months ago by
Replying to cypherpunks:
Not sure if it's correct to leave it in the
Tor: 0.3.5.x-final
milestone.
It's tagged with 035-backport-unreached. When 0.3.5 closes, all its other open (unreached) backports will also be tagged with 035-backport-unreached.
Edit: open backports are tagged with 035-backport-unreached
comment:17 Changed 9 months ago by
Yes, but that means they don't have anything related to the Tor: 0.3.5.x-final
milestone.
Here's the pull request:
https://github.com/torproject/tor/pull/551
The code is based on #24661 and maint-0.3.5. It also includes #28654. (I'm not sure if #28654 is a good idea, but it makes sense to be consistent.)